Bugzilla – Bug 3985
Comments causing parsing mistakes
Last modified: 2006-08-25 14:34:57 UTC
Gentleman, I'm having a strange behaviour with my SlimServer scanner. First of all I confess that I hate MP3 files and the whole thing with the tagging world. FLAC, APE, OGG, etc seems to have better standards. :-) Well... but I have a problem in here and looks like a bug. I have some songs that as usual were wrongly tagged or are part of a album "release" that nobody ever saw complete. In order to keep my library organization I corrected the tags to my taste but added a comment with the original tags, for historical purposes. Seems like the comment tag fools the tag parsing. I'm also attaching 3 versions of the same mp3 file. One contains is the "original file", with the id3v2|id3v1 tags, including the comment tah. The other two, are my debuging files. One contains only the id3v2 and the other contains bith id3v2 and id3v1 tags, but I removed the comment tag. The last file(without the comment) is the only one that SlimServer is parsing. PS: yes KDF, I could have posted this before on the forum... :-)
Created attachment 1464 [details] original file with id3v2, id3v1 and the comment tag.
Created attachment 1465 [details] file with comment but with no id3v1
Created attachment 1466 [details] file without comment
why didn't you? (sorry, I guess I could have been more helpful, but I'm tired ot time wasting)
Ross, could you have a look at reproducing this?
There is indeed something wrong with the way the tags are handled within SlimServer for the first 2/3 of these files. However, I'm also noticing something strange when looking at these tags with Mp3tag. In the Comment tag (clearly the one causing this problem) it seems there are box characters. When I removed those boxes from that tag, it works fine. I'll attach the file with the boxes removed from the comment tag.
Created attachment 1469 [details] boxes removed from comment tag, see mp3tag
I'll also attach a screenshot that shows in mp3tag the 3 files. The first file is the one I corrected, by removing the boxes. The second file is the one that doesn't parse properly in SlimServer. The third file looks like Andre just removed all the data in the comment tag.
Created attachment 1470 [details] screenshot displaying tag problem
The 'boxes' are often how windows deals with characters for which it doesn't currently have a character set installed.
or perhaps NULL characters?
Andre, Could you let us know what you think about the tags? I'm thinking these tags just need a little more TLC.
Ross, TLC stands for tender loving care? :-) Well, I don't mind about changing tags present in around 30, 50 files but the fact is that those tags were made by a simple procedure using foobar2000, which is a quite popular mp3 player and converter whose use is "suggested" on SlimDevices Wiki. The procedure was simple. Copy tags, add/edit comment tag. Paste foobar clipboard content into the tag edit window. Nothing special in my point of view. Foobar problem? I can agree with that but also a scanner.exe bizarre behaviour at the point that it reads and partialy parse the id3 contents. If I can take special care with the tags? Of course. What you suggest?
Andre, Foobar2000 is indeed a great application. Have you had a chance to download MP3tag to see what what I was trying to show with the attached screenshot? With that and some help from Chris Owens I was able to take a closer look at the 'blocks' to see what they actually are. There are line feeds, and return carriages in your tags, which do not belong. In other words these tags are corrupt. I'll agree, that looking at these files in Foobar2000 they look as they should, however this probably just means that Foobar2000 omits the inappropriate characters, MP3tag & SlimServer do not. How/when did these tags become corrupted? Hard to say, probably not really worth diagnosing. If it's only a few files you can fix them manually, if it's a lot perhaps you should take a look at mp3 tag repair utilities... TAG&RENAME comes to mind, however there are many options.