>yes it is, from the POV of how andy explained SBS will work now, it >is. > Andy has agreed that FLAC should take precidence, which is better.
>>So by making this change to fix your specific small number >> of incorrectly tagged files, it has introduced a change that could >> affect a lot of people. > >what nonsense. first of all, the problems are not equals, the one i am >trying to fix is far worse than the one erland is reporting. > In your opinion, because it's fixed your fault, but there's no evidence that that is a widespread issue. It's certainly only a localised issue to id3v1 and id3v2, and then it's an odd situation. Erlands FLAC tags were okay, and his SbS library was okay. It could even be that the id3 tags are okay. But with the change, it now takes a combination of both tags. One could dream many examples where subtle unwanted changes in library content could occur. For example, FLAC tags may have an ALBUM ARTIST tag. id3v2 tags may have a TPE2. Will the album artist be the value from ALBUM ARTIST, or from TPE2? Will the scanner record both values if the two are different? Will it matter if TPE2 is set to represent BAND or ALBUM ARTIST? A FLAC file may have an ALBUM ARTIST tag and not a COMPILATION tag, whereas the id3v2 tags may have an iTunes TCMP tag. In the scenario where it only read FLAC tags, it would result in a non-compilation album with an album artist. In the case where it only read id3 tags, it would result in a compilation album. In the case where it merges both sets of tags together, you get a weird compilation album with an album artist set. Artwork could be another case: what would take priority, an id3 embedded image if there's no FLAC artwork tag, or a Cover.jpg or folder.jpg? Perhaps it is partially safe to think of merging id3v1 and id3v2 together, but different tag formats can have wider implications (many more permutations, harder to test all paths). >secondly there is no reason to think the one i am reporting is a >smaller population than the one erland is reporting. There is no evidence to suggest one population is bigger than the other. But there are reasons to think one could be more than the other. I'm not going to get all hung up over numbers, evidence, reasons, suggestions, blah blah. >since mp3s are FAR more common, its far more likely erlands issue >is NOT the bigger population. You're right - mp3's are probably more common than any other format. But that doesn't necessarily mean the embedded tag formats are. Your problem was I think constrained to id3v1+id3v2, whereas the effect must be a greater population, because it can be any combination of tags, including id3v1+id3v2. >thirdly, erland proposed a bug i voted for, that suggests that each >file type should have its own tag priority. that makes sense if andy >can do it, and doesn't at all invalidate 8380. > I assume that every file type used to have it's own tag priority. i.e. per file, one tag won over all other tag formats. The change I guess altered the order the tag formats were read. >finally, his situation is the result of undesired "bad tagging," whereas the >one i describe isn't. The one you describe is bad tagging. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
