erland;275333 Wrote: > Some unique identifier that survives renames/move of music files is > needed if SlimServer stops discarding the whole database during rescan. > I agree that in this case some kind of audio data hash would be > preferable over musicbrainz id's. The reason is that all people aren't > going to have musicbrainz id's on all their music so we need something > more than musicbrainz id's. > > I guess the same situation also might apply if the tagging information > is stored in separate xml files instead of the music file themselves. > > If SlimServer could store some audio data hash for each music file > (independent of file format), that would make the synchronization > during and after a rescan a bit easier. >
Adding SC this stable file ID would be a very big step forward and it could be used as a base for a whole new set of functionalities and improvements... MD5 checksums of mp3 audio data shouldn't be too difficult(1), and it's already a part of flac format. I wonder what logitech SC software director would think about this idea. I also wonder what would be the drawbacks/difficulties/side effects of this. AFAIK, with SC what looks like very small changes can be a lot more complex that it seems at first glance. As the XML file is an "independant data holder", it's not tightly bound to the media files. When I get tags from FreeDB, Discogs or from Amazon, sometimes there is "track" information, sometimes there isn't but I record both. Furthermore, in the real world, a track is sometimes tied to a given media file, sometimes the whole tracks are tied to a single media file. The only assumption I made was the "one folder or folder/subfolders for an album, and one xml by folder". When it comes to tag media files from the XML, the tool is looking for every media file in the subtree and it orders them either with TRACK tag information (track number tag) if it's consistent, either with a natural sorting of the folder/subfolder/filename names. As long as the assumption is ok, this design permits the user to choose its own naming pattern, be it: disc1/01 d.flac disc1/02 e.flac disc2/01 b.flac disc2/02 a.flac or 1-01 d.flac 1-02 e.flac 2-01 b.flac 2-02 a.flac Even if a flat number free naming scheme like: d.flac e.flac b.flac a.flac is possible as long as you correctly fill TRACK and DISCNUMBER tags. And as long as you respect those few constraints, XML data survive move and rename actions. (1): This code ( http://homepages.uni-paderborn.de/sgeseman/Mp3d5.java.txt ) shouldn't be too difficult to translate in perl, furthermore, it's already part of other tools like mp3tag: http://www.hydrogenaudio.org/forums/lofiversion/index.php/t42276.html -- vrobin ------------------------------------------------------------------------ vrobin's Profile: http://forums.slimdevices.com/member.php?userid=11705 View this thread: http://forums.slimdevices.com/showthread.php?t=43851 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
