Bugzilla – Bug 8380
Album missing when it has no tags
Last modified: 2011-01-14 12:57:41 UTC
Created attachment 3419 [details] mp3 with only RG info in id3v2 and more info in id3v1 hi, i wouldn't call this a huge bug, but apparently, if your mp3 has id3v1 and v2 tags, and v2 is blank except for (in this case) replay gain values, then that track or album won't show up at all in the SC library. please see the URL. the biggest problem is that when you have hundreds or thousands of albums, its hard to notice one is missing from the library. i just happened to by luck. so i propose that instead of having SC use the v1 info to fill in whats missing from v2, (ergo just 'masking' the issue) it should instead simply populate "no id3v2 info available" for the artist field (and track title field) if thats the case. that would then keep the album from being "missing" in the SC library, and identify it as one that needs its tags checked out to the user. some users leave the album field blank on purpose, so populating that probably wouldn't be a good idea. i figured this issue should at least be documented. i will upload a mp3 so u can reproduce it.
Not using v1 tags if there's no information in the v2 will cause a lot of hassle for users who didn't bother upgrading their tags. I'd bet even you would cry out loud.
i don't think you understand what i said. SC7 already doesn't use v1 info if v2 info is missing. thats part of the problem. if the only v2 info available is replaygain info, then the album/tracks just don't show up in the library at all, (or if they do, not in a place known to me) scan my file, see what happens.
Well, your track doesn't have any artist/album/track tags set at all, neither v1 nor v2 (checked with four different apps, including mp3tag and EasyTag), and it still shows up in my SC. It's in the "No Album" album, and its title is its file name (without the extension).
I see the following tags in the attached file: ID3v1: ALBUM Back In Black [ReMaster] ARTIST AC/DC GENRE Rock TITLE Back In Black YEAR 1980 ID3v2.3: REPLAYGAIN_ALBUM_GAIN -9.15 dB REPLAYGAIN_ALBUM_PEAK 1.090151 REPLAYGAIN_TRACK_GAIN -9.64 dB REPLAYGAIN_TRACK_PEAK 1.135243 Note to self: I need to find an easy way to dump all the raw tag data to a text file.
> I see the following tags in the attached file: Ahm... what am I doing wrong?!? What app are you using?
well, i'm not sure what the problem is with what you are doing, BUT i see what steven sees. i use winamp. as to seeing it under "no album" when i look under N in my SC library, i don't see it listed. should it be called "No album" and therefore under "No" ? my albums go nirvana to norah jones to nudeswirl. no untitled "no album" in there.
(In reply to comment #5) > > I see the following tags in the attached file: > Ahm... what am I doing wrong?!? What app are you using? I know Mp3tag works very much like SqueezeCenter. If there are both ID3v2 and ID3v1 tags then it will only "see" data in the ID3v2 tag and ignore everything in the ID3v1. I suspect most tagging apps work like this. It's an old issue... Should SqueezeCenter try to intelligently merge tags (APE and ID3v2 and ID3v1) or set a hierarchy and use only data from the highest priority tag. Merging has it's benefits, but also can lead to a lot of confusion if there are conflicts between the data in two different tags. I think it's been pretty well established that SqueezeCenter uses a strict hierarchy, so don't think that issue should be debatable at this time. The gyst of this particular bug seems to be: What do you do with a track when you have no track name? A missing album name is handled by the "No Album" pseudo-album. But no track name? Do you make one up using a random number or something?
jim is talking about this bug: https://bugs-archive.lyrion.org/show_bug.cgi?id=4665 but he is right, the issue i am discussing here is different. Jim, my answer to your question is that if an artist name or track name is totally missing, SC should populate those fields in its library with the same string of "Missing tag info" that way, all such tracks would be identified and grouped together, and people could then know they need to fix them.
Michael, framelist, which is part of taglib, seems to work great at dumping all tags from an mp3 file. You can find a link to a windows binary near the bottom of the taglib site at http://developer.kde.org/~wheeler/taglib.html I was hoping to find a Mac OS X binary as well.
So wait, are we still defining what bug actually exists here? Looks like this is going to miss the 7.1 release.
no, the bug is defined imo. i assume the following is true for ape as well btw. but IF a given file has id3v1 or id3v2 info BUT that info does NOT include artist, album, or track info, it is MISSING completely from the library. when looking at tags SC uses whatever it finds first in this order: APE id3v2 id3v1 if it finds no ape, it goes on to v2. if it finds v2, but all that is in v2 is a RG tags, it doesn't care, it stops there, and does not look at v1. so, if the v2 tag has no artist, album, or title info, it is then still scanned, but not seen in the library. what SC needs to do to fix the issue, is put a set string in the artist and title field of: "Missing tag info" that way the problematic tracks are identified to the user, AND the music is still accessible via SC.
sorry, this line: "...BUT that info does NOT include artist, album, or track info,..." should read: "...BUT that info does NOT include artist, album, AND track info,..." i should also note that i have not tested to see what happens if any one of those three fields is filled out, while the others are blank. would be a neat experiment. but the file i uploaded is enough to reproduce the 'all artist/album/track info missing' situation, which is what i am reporting here.
Steven this sounds like it should be part of your tag project. Is there a master bug or keyword for that, yet?
Chris, I have not yet made a bug specific to tag reading. Do you think it would be appropriate to create one like we did for new schema bug 8303? Perhaps tag reading should be part of or at least linked to that new schema bug.
ok, somewhat strange thing to report, but i think i know why... back in black (the album and all tracks) is now showing up in my library again, its listed as the first album (in artwork-artist-year-album view) but the year isn't there, (which is why its first in the sort) even though the year is in the v1 tag. so i don't think it is reading the v1 info. i think the reason it has reappeared, is because i changed the first setting for guess tag formats to be this: /ARTIST/ALBUM/ARTIST - TRACKNUM - TITLE which is a lot closer then what the default previously had. i just thought i should mention this. i still think everything i said preveiously in this bug stands.
clarification: when i say its listed as the first album, i mean of AC/DCs albums, in that area. in any case, as i mentioned, this bug can be effectively mostly (not totally) masked IF the user has the right formula in guess tag formats, but if they don't, the albums affected will be missing. so, i think the solution is to put in a single string in the artist and track fields of "missing tag info" if thats the case. (it would be even better if you could ID which layer is missing, ie. "missing id3v2 tag info" which would indicate to the user they have some other v2 tags, just not any for artist or track) is this going to be addressed in 7.2? are we all agreed it exists as described?
Adding new_schema keyword for future discussion.
this bug has the keyword, but hasn't been added as a block to bug 8303 i assume thats an oversight?
another possible scenario is when a file might have no tags at all of any kind anywhere. what does SC do for tagless files that it can't "guess" properly via filename/location? i believe that SC should populate the SC DB with SOMETHING when the tag has blank artist and title fields. like i said in 16, it would be good to ID the tag layer if other tag fields were populated, (like RG).
regarding comment 3 i am curious how/why mherger was able to see my file in SC as the filename? i would think it wasn't b/c of guess tag formats, or else it would have parsed the filename correctly, right? could it be that SBS acts differently with this tagless scenario depending on what platform its running? in any case, on XP for sure, its an issue.
== Auto-comment from SVN commit #492 to the opensource repo by andy == == https://svn.slimdevices.com/opensource?view=revision&revision=492 == Fixed bug 8380, read multiple ID3 tags when more than one is found, such as ID3v1 + ID3v2
Andy, its great this bug has been addressed, but if you "merge" tags, isn't that just masking a bad tagging issue? what happens when the tags are divergent in data? i'm just curious as to how exactly this was fixed, and if it might introduce "other" problems...?
also, what if a file has no tags at all, of any kind, and guess tag formats doesn't work?
By "merge" I just mean it reads both ID3v1 and ID3v2 tags now, preferring the v2 tags over the v1 if there are any duplicates. If a file has no tags at all, I don't know, you should avoid this situation. :)
agreed, but some customers won't be sophisticated. my suggestion? put the actual filename in as both artist and title. that way it will at least show up in SBS and people will learn the importance of tags. doable?
I guess I only fixed part of this bug (the one shown by the attached file). I didn't realize there was a larger issue.
andy, i hope you know i think you're great! and i appreciate what you've done here, so just in case, please understand i think you're the man at logitech, no doubt about it in my mind. and there is no doubt you fixed the issue represented by the attached file, but that was just a portion of the problem. but the bug itself is called "album [aka files] missing when it [they] have no tags" and i can tell you, as someone who downloads p2p every so often, this is not a rare thing. i'm just trying to help logitech "dummy-proof" SBS, thats all, this is meant just to help the software get less support calls. i learned the importance of tags long ago, but i did learn the "hard way." this suggestion isn't to bedevil you but rather to help people "see the light." as always, thx for your contributions, which frequently amaze me.
Thanks. :) I think your suggestion of putting the filename in both artist and title would be quite ugly, but I agree "guess tags" is a hopelessly lost cause. The kind of person who has no tags is not very likely to have a sane directory structure. I honestly have never looked at the guess tags code so I don't know what it does. But I agree we should never hide a file completely just because it has no good tags.
i totally agree with you. i can say that "guess tag formats" does work IF the person has a pattern to their filenames and reproduces that pattern in the SBS fields. (my pattern wasn't in the SBS defaults btw) my no tag files showed up with the right pattern entered. unfortunately, it has to be EXACT and it will never help those with p2p files. i agree my solution is "ugly" but it does keep the files from simply not showing up, and actually being "ugly" is good b/c it will prompt users to figure out WHY its ugly, which ultimately would, i hope, get them to address their poorly tagged collection. what you could do, is make it a stage of guess tag formats. so, it fails to populate the DB b/c it has no tags, then guess formats fails b/c it doesn't match the pattern, and so as a final hurrah, the filename is used to populate artist/title for the DB. elegent? no, but effective. thanks for keeping an open mind on this, and i hope i didn't sound over the top in my praise. i know i push issues but i just like to see complete solutions. thx again, :)
Andy, do you want me to upload a file with no tags so you could account for files like that as well? using the filename for artist and title is the only thing i can think to do, and have it happen as the final stage of "guess tag formats" if that fails after not finding any real tags. is this something you'd put in the test library?
Thanks but I already have a test for guess tags. :)
sorry to belabor things, (i know i do it a lot), but does the test suite for guess tags include files that have no tags AND will NOT be "guessed at" correctly?
Nope, but that's a good idea.
(In reply to comment #20) > regarding comment 3 i am curious how/why mherger was able to see my file in SC > as the filename? > i would think it wasn't b/c of guess tag formats, or else it would have parsed > the filename correctly, right? could it be that SBS acts differently with this > tagless scenario depending on what platform its running? > in any case, on XP for sure, its an issue. also, it might be because mherger did not look in Home > Albums the behavior for these tagless files is different depending on how one navigates SBS.
7.4.x milestone is in the past
(In reply to comment #33) > Nope, but that's a good idea. ok, so has such a test case since made it in?
If both tagging and guess tags fail return an empty string for a track title then why not just use a hard-coded (translated, I'm sure) string of 'No title', as is done with 'No album'? An empty artist string could be handled similarly: 'Unknown artist' or just 'Unknown'.
(In reply to comment #37) > If both tagging and guess tags fail return an empty string for a track title > then why not just use a hard-coded (translated, I'm sure) string of 'No title', > as is done with 'No album'? An empty artist string could be handled similarly: > 'Unknown artist' or just 'Unknown'. i think even better than that would be "missing tag" or "missing tag layer ####" if it had some tags, but not a title or artist tag. the issue is much improved since Andy designed it to intelligently merge tags, and he did a great job with that, so i don't mean to nitpik, but this last issue remains outstanding, and it isn't so prepostureous to think it occurs, i can tell you its common on p2p files, and someone could have wav files for instance that get overlooked.