Looking for a solution that I'm not sure exists
#1
Posted 19 February 2013 - 12:24 AM
Here is my scenario: I have a folder with music albums. I want to add metadata to these but I want to keep the original unmodified files as well. I'm searching for some way to be able to access either file versions but I really don't like having to keep all the redundant data around.
#2
Posted 19 February 2013 - 03:37 AM
Cheers and Regards
#3
Posted 19 February 2013 - 06:19 AM
#4
Posted 19 February 2013 - 08:13 AM
Quote
EDIT: LOL I'm going to have to get my glasses fixed.
Cheers and Regards
This post has been edited by bphlpt: 20 February 2013 - 02:37 AM
#5
Posted 19 February 2013 - 01:42 PM
Are music albums recorded to JPEG's or PNG's?
@selyb
More seriously, which format are those "music albums" stored in? .flac. right?
http://flac.sourcefo...net/format.html
then:
http://xiph.org/flac...s_metaflac.html
The issue is really about possible bugs in metaflac (or similar tools), in theory it is possible to strip (saving them to files) the metadata and later re-build the original re-adding the metadata.
Remember
Quote
jaclaz
This post has been edited by jaclaz: 19 February 2013 - 01:43 PM
#6
Posted 19 February 2013 - 02:34 PM
Just select a file, then add a Key (e.g. "Artist") , then add the data (e.g. "firstname lastname"). On subsequent runs if data already exists for the file selected it will display that data prior to the inputboxes. It will build the ini in the directory the script is ran from.
#include<array.au3>
$file = FileOpenDialog("Select File" , @ScriptDir , "ALL(*.*)" , 1)
$aINI = inireadsection(@ScriptDir & "\metadata.ini" , $file)
If @Error <> 1 Then _Arraydisplay ($aINI)
$key = inputbox("Add Key" , "What type of data is this (one word)" , "Artist")
If @Error = 1 Then Exit
$input = inputbox("Add Data" , "Add the Data" , "FirstName LastName")
iniwrite(@ScriptDir & "\metadata.ini" , $file , $key , $input)
This post has been edited by iamtheky: 19 February 2013 - 02:35 PM
#7
Posted 19 February 2013 - 05:50 PM
This post has been edited by selyb: 19 February 2013 - 05:51 PM
#8
Posted 19 February 2013 - 06:47 PM
#9
Posted 20 February 2013 - 12:16 AM
If it's on the same hard drive and different files, hard links would work but only in this case. Other than that, you'll need most likely a tailor made tool to do what you need.
#10
Posted 20 February 2013 - 12:33 AM
Let's say I have a small business and I install Linux distros on client's computers. For the good of the community, I share these distros back using bittorrent. Let's say that in every one of the ISO's I like to insert my company logo as a default desktop background and the most efficient way to do this is to modify the ISO. In this scenario, I may have 50 different 4.6GB ISOs that I share on bittorrent and 50 more that are my customized versions. The difference between each original and it's customized version is only a couple megabytes so 99% of the data is the same between each pair. Bittorrent is not going to ignore any little part so there is no way (that I know of) to share only that 99%.
The solution I had in mind is by using something like a small diff patch, I could give programs access to two different files while most of it points to the same data. Currently, I use hard links to the same data from multiple file names. What I need is some way to (for example) have "c:\somefolder\somefilename" point to "c:\otherfolder\otherfile" with "c:\patchdata\otherfilepatch". In this way, Bittorrent could share the original file and Imgburn could access the modified file but I don't have to lose nearly 50x4.6GB of redundant hdd space.
#11
Posted 20 February 2013 - 02:37 AM
#12
Posted 20 February 2013 - 03:27 AM
Edit: fixed mistakes and missing words.
This post has been edited by allen2: 20 February 2013 - 03:30 AM
#13
Posted 20 February 2013 - 08:43 AM
The "patch" route is not really feasible/useful/smart.
The "patch" is "smart" when you have a binary file and you have to replace a given set of bytes with another one (SAME number of bytes).
Size of the file before and after patch is the same.
In the case of .iso you can "simulate" the patch by replacing a whole file with an empty file (or a modified one) of the same length.
(as an example, Winimage can do this)
This allows to NOT alter in any way the filesystem indexing tables.
Otherwise you need a .iso editor (let's say MagicIso or PowerIso or the like), i.e. a tool that rebuilds the indexing. (and that from experience works - say - 95% of the times BUT it is not totally error free).
The case of any file which includes metadata is very similar to the .iso one, you can do the same by replacing the "filled" metadata fields with empty ones, BUT you cannot remove or add a metadata field without re-indexing/re-creating the whole file (otherwise a tool like metaflac would have NO reason to exist).
bphlpt, on 20 February 2013 - 02:37 AM, said:
Naaaah, let's fake
jaclaz
This post has been edited by jaclaz: 20 February 2013 - 08:47 AM
#14
Posted 20 February 2013 - 11:09 AM
(link to homepage at bottom)
Works fine - any size difference. Generate DeltaFile, delete Original, run DeltaFile against Modified to reproduce Original. Bear in mind the HDD FileDates will not be retained so you'll have to keep a log of that and a Date changer program.
Syntax -
http://code.google.c...mmandLineSyntax
HTH
This post has been edited by submix8c: 20 February 2013 - 11:16 AM
#15
Posted 20 February 2013 - 11:46 AM
submix8c, on 20 February 2013 - 11:09 AM, said:
Of course there is no issue with making an Xdelta between two files even if they have different sizes
But you don't have available at the same time the original and the patched file. (unless you keep the original
I mean OP now has 2 Gb of files (originals) AND (almost) 2 Gb of files (stripped) = total (almost) 4 Gb.
By making delta files for all the originals he will end up with (almost) 2 Gb (stripped) and (say) 50 Mb of xdelta files = total (roughly) 2 Gb.
He needs to have the (almost) 2 Gb of stripped files "available/accessible", but everytime he needs one of the "originals" he will have to recreate it on-the-fly applying to the stripped file the xdelta patch.
What I got from the original request was *something* that allowed to have AT THE SAME TIME available the "original" and the "stripped" versions of all files BUT saving the space.
This cannot be done with "ordinary" means.
What the OP asked for (again IF I got it right) is *something* similar to these:
http://khenriks.github.com/mp3fs/
http://blog.einval.c...ware/fuse-music
which I don't think actually exists
jaclaz
#16
Posted 20 February 2013 - 05:11 PM
jaclaz, on 20 February 2013 - 11:46 AM, said:
...
What I got from the original request was *something* that allowed to have AT THE SAME TIME available the "original" and the "stripped" versions of all files BUT saving the space.
I agree with your understanding that he want's both versions available at the same time, but I think you have it slightly backwards. I the think the originals ARE the stripped versions. The ones he adds have metadata ADDED to them.
selyb, on 19 February 2013 - 12:24 AM, said:
Not that that makes any difference to your conclusions. I don't think that is currently possible to do, though I can see it would be handy. As of now, an external file with the added info, or "duplicate" copies as he is doing now, seems to be his only options.
Cheers and Regards
#17
Posted 20 February 2013 - 11:59 PM
- file1 -> partA + partC
- file2 -> partB + partC
BTW, working on windows would be a perk but is not required. I can install the solution on a linux box or VM and share the folder(s) with RW permissions.
#18
Posted 21 February 2013 - 02:40 AM
IIRC, VideoLan and VirtualDub both have a video/audio server mode that can create streams on-the-fly from separate audio and metadata files. And Quicktime / MP4 file formats support metadata physically present in the file along with audio tracks that are referenced from another file (the original FLAC file in our case here). Perhaps there are also other ASX or playlist formats that would suffice.
#19
Posted 21 February 2013 - 04:15 AM
The shortcoming of this approach is that decoding/re-encoding the file on-the-fly (and upon request) will need some (a lot of) computer power.
Think (very simplified) to gzip.
The gzip compression format is "pipable", so you can well keep your files gzipped, and have them uncompressed on the fly transparently, but this saves space at the cost of CPU cycles.
It is possible in theory to make a .flac FUSE filesystem capable of stripping on the fly the metadata, which should be fairly simple and not hogging the CPU, but I don't think there is one already made:
http://sourceforge.n...tle=FileSystems
Another couple examples:
http://amaras-tech.c..._flac_to_mov_fs
https://www.uitwisse...projects/yacufs <- this one is seemingly dead
http://cuemounter.codeplex.com/ <- Windows
About the:
- file1 -> partA + partC
- file2 -> partB + partC
IF the metadata is contained exclusively in the first part (or - if you prefer - part C is NOT metadata) it is also possible, though again I don't think something already exists.
Just for the record, here is that concept applied to the whole filesystem (nothing you can actually use, just a "demo" or PoC), meet Overlapping FileSystem
http://reboot.pro/to...ub4dos/?p=19803
(idea was never actually finalized as there was little interest and it 's use would have been however useful only for very "narrow" scopes)
jaclaz
#20
Posted 23 February 2013 - 06:17 PM
- ← All-in-1 w/Mirror, Backup, Incremental, Differential & Instances?
- Software Hangout
- Codeit HTML Editor.NET 1.22 MSFN Edition →



Help
Back to top









