On Mon, 2005-11-07 at 10:32 -0500, Geoff B wrote: > That said, if all we're wanting to do is (a) store some extra data > about each track and (b) make use of that data in the Slimserver UI, > why not leverage the existing tag options available with MP3 / OGG? > Building and maintaining data separately to the file is always going > to cause unnecessary problems.
Extending and providing locally defined tags is clearly one option. I just don't see that it really solves anything in a particularly clean way. Suppose you add a tag for "PerformanceLocation" in the metadata within the file, using suitable ogg/id3v6 format. What happens with ID3v7 uses the same tag in a different way? And you have to both tag all your tunes and keep the slimserver parsing code in sync. Of course, the rules of code reuse encourage using a normal CPAN library function suite, so now you have to have your local tags, plus the slimserver plus the CPAN library all in sync, all with proper upward and downward compatibility across versions. > Does the metadata refer to the music > data by filename (what happens if you want to systematically rename > your music files)? By some ID tag? You then need a UI of some kind > (as discussed) to allow easy manipulation. You then need to train SS > to find and *read* this external metadata. This points to a key design decision. What is a song? I proposed in early 6.0 design stages that the file name is the worst choice for identifying songs. One of the strengths of the internal tag idea is that you can copy, rename, move, or even trade songs and still have it tell you what song it is. File names, directory structures, etc. get changed all the time, and changing them should not change the essence of the song/track/movement/piece. This raises the question of what is the essence of a song. When are two songs identical? There are lots of potential definitions. The most obvious is that songs are identical if a hash/checksum of the bytes is identical. I proposed that we only consider the music part of the file, and skip all the metadata tags. I think that changing one of the tags within a song, say Genre from Pop to House does not change the essence of the music. So I proposed that we read the whole file, ignore the tags, headers, and assorted BS, and put the music bytes thru the hash function. And store the resulting hash. > Someone who knows about MPC and WMA formats would have to chime in on > solving it for those cases. WMA and AAC are great examples of why using tags is not sufficient. The internal format of these files are proprietary. You may be able to reverse engineer the format for any specific version, but you will have to repeat it for each modification that Microsoft or Apple make. > From there, it's matter of DB-persisting the tags as part of the > normal scan process, I'm convinced that for my needs, no extension of metadata tags is sufficiently robust to describe all the data and can not be made applicable to all file formats and versions upward and downward. In general database work, information retrieval work, etc. the separation of data from metadata is well established. For many good reasons. I don't understand why so many folks seem to be insisting on using extended tags. Patches are always welcome. Nothing that I'm written about prohibits other approaches. There is no one true way. I am sure that I'll write the first couple of generations of patches to implement this. Maybe if folks like it, they'll use it and encourage the greater developer community to further enhance it. I don't see this as needing agreement, we can have it both ways -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
