>i don't follow you. can you demonstrate a test case of the problem you forsee? > I already did, further up the thread, and someone else did too. Many people rip single songs from CDs (or incomplete album rips), and thus subsequently edit tags to remove the album name, so the songs appear under Artist->No Album. If the ripper sets id3v1 and id3v2 tags, and the user removes the album name post rip, the id3v1 tag will be retrieved, not the blank id3v2 album name.
Now, if all rippers and editors always set/clear id3v1 and id3v2 tags, then there wouldn't be a problem, but conversely, there would never be a need to merge multiple tag blocks together because the last one read would be the final result. Another point: multi-value tags that have different content are to be merged. So, if you set comments you get id3v1 comments and id3v2 comments where they are different to id3v1 (to avoid duplicates). However, id3v1, being a bit rubbish, has a max size, after which text is truncated, so potentially this would not be seen as a duplicate, and you'd end up with two comments, the first being a truncated version of the second. What about artists - will it merge the set of artists together, or will id3v2 override id3v1? This isn't the case for comments. What about genres - id3v1 have id's for fixed genre lookups. Will this be merged with id3v2 or overriden by id3v2? Other formats may have other nuances. It makes for more complex rules (both code and explanations). That may lead to slower scan times, larger mem usage. >b/c SBS is not a tag editor, its a music server. its main focus is >playing the music you have. it can't do that if your files don't show >in the library. > Music will show up, even if artist, album and song are blank. They will appear within No Artist->No Album. If it's wrong, fix the tags. >(the scenario, which u can reproduce from the file attached in the bug, >was v1 files later having RG tags applied. in that case, ONLY RG was in >v2, the rest of v2 was blank. still looked fine in winamp (and other >apps), but missing all together from SBS) > Is that really a case that happens a lot? Firstly, not many people rip/edit with id3v1-only tags, secondly the people who do, are they likely to add replaygain tags using a tool that reads id3v1 tags but only sets replaygain tag data in id3v2, without rewriting all tags back out as id3v2? It sounds rather unusual/wrong. >in the past you have always argued for SBS to *show you* whats wrong in >your tags. well, how can it do that if it doesn't even show you >anything? > Yes, I think displaying the raw tag data for a song is a reasonable idea. If a song doesn't appear in the library where expected, then the user could look in song info > tag data to see what tag scheme was read, and what other tags appear in the file. Then the user can fix it. >well, i said it above, but most users use mainstream apps, and most >mainstream apps by default keep v1 and v2 congruent, to avoid confusing >discrepencies in their own native usage. > >again, the problem is when a specific v2 tag is applied, like RG, when >a file only had v1 tags to start. not all apps copy v1 into v2 when the >RG (or whatever) is applied. > Aren't those two paras are contradictory? You're saying that most apps write id3v1 and id3v2 tags to avoid discrepancies (although this by default causes discrepancies, because id3v1 is a very small subset and truncated strings), but applying replaygain to an id3v1-only file could write id3v2 replaygain tags without keeping v1 and v2 congruent. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
