The NEW Build Your Own Arcade Controls
Software Support => DOS/WinCab => Topic started by: FrizzleFried on October 08, 2008, 02:52:52 pm
-
Alright...I've put a major effort in to cleaning up my tags, etc in the juke...but with about 10,000 songs it's a pain in the ass for sure.
I've always had situations where albums are unexplainably broken up in to 5 or 6 "albums" in the juke...but I don't know why. All the tags appear identical to others that work perfectly.
Example: My NOFX CD with 8 tracks is actually showing up as 8 different albums with a single track in each...but the tags are formatted the same as my other NOFX album that has 9 tracks in a single album. What gives? What field do I have to look at to prevent the multiple albums thing? I made sure each song had the "track" fields included (1, 2, 3, etc)...
-
Alright...I've put a major effort in to cleaning up my tags, etc in the juke...but with about 10,000 songs it's a pain in the ass for sure.
I've always had situations where albums are unexplainably broken up in to 5 or 6 "albums" in the juke...but I don't know why. All the tags appear identical to others that work perfectly.
Example: My NOFX CD with 8 tracks is actually showing up as 8 different albums with a single track in each...but the tags are formatted the same as my other NOFX album that has 9 tracks in a single album. What gives? What field do I have to look at to prevent the multiple albums thing? I made sure each song had the "track" fields included (1, 2, 3, etc)...
I wonder if when you made changes to the tags the date and time on the file didn't get changed? If the timestamp doesn't change it won't re-read the tags.
-
I have seen extract the same problem in MultiFE when I was changed engine. It was happens when MultiFE diddent read unicode correctly and have readed a char to much and then treated like thier own album, but for some reason the extra char was never shown (I guess because its got null terminated in "first" byte").
Can this been the same issue (if it reappear after updating the timestamp)?
So check if they using 16bit strings or not.
-
Can anyone recommend a TAG utility that is at least semi-automatic that could correct this issue? I have all my songs in individual folders, each with band name and album name...it would be just dandy if there was a utility that would go through them all and create proper tags for them all.
-
Can anyone recommend a TAG utility that is at least semi-automatic that could correct this issue? I have all my songs in individual folders, each with band name and album name...it would be just dandy if there was a utility that would go through them all and create proper tags for them all.
Tag and Rename is the one I always hear about, but I haven't actually used it.
If your songs are in folders by album and artist, you could turn off ID3 entirely and just use those.
-
This could been a bug in your code, because unicode is not readed correctly. The bug is about the length of them is not detected correct and you propenty might have forget to -2 (or -1? depend how you detect the length)after length is detected.
I guess you should test it by your self by using a unicode based tag by one of the albums and see it.
I havent tested it, but I have seen extract that bug in multiFE but got it fixed.
My self I use ID3-Tag IT or tag Scanner as by ID3 tagger app.
-
This could been a bug in your code, because unicode is not readed correctly. The bug is about the length of them is not detected correct and you propenty might have forget to -2 (or -1? depend how you detect the length)after length is detected.
I guess you should test it by your self by using a unicode based tag by one of the albums and see it.
I havent tested it, but I have seen extract that bug in multiFE but got it fixed.
My self I use ID3-Tag IT or tag Scanner as by ID3 tagger app.
The thing about Unicode is that the ID3 spec says to always use 16 bit Unicode, and there is a Unicode marker that's supposed to be on the text. But some tag apps seem to write the Unicode without the tag, some write in UTF-8 rather than 16-bit Unicode, and some use Latin-1. Microsoft's Media Player seems to be able to detect these incorrect encodings and figure them out anyway, but I'm just not that good, so unfortunately my program does require the tags to be written according to spec.
However, if he used the same program to edit his tags, I wouldn't expect this. Even if it's writing them wrong, they should all be wrong in the same way.
-
I just downloaded and tested it. Yes, it happens here too with same albums that did for MultiFE. So I just can say it a unicode bug in your code.
You propenty have forget to shorting the detected unicode length string by 2, which cause add some garbage char and then treated like its own album....
-
Something strange is going on when your software creates it's .DB file from ID3 tags. Abot 30% of my albums end up with multiple covers because for some reason, when creating the .DB your software is adding strange characters to ALBUM NAME, ARTIST NAME, SONG, and sometimes GENRE too...randomly. Sometimes a tag will have one with strange characters, sometimes two fields, sometimes all fields!?
I also notice that sometimes the strange characters (little rectangles mostly) include the the ending characters of the SONG NAME for example, under the ALBUM NAME...
So if the SONG WAS "There is Something Wrong" and the Album was "All Messed Up", the Album name would end up like "All Messed Up(wierd characters + boxes)omething Wrong"....
Also, it appears that the program will crash out while creating the .DB if the name of the file being created, including path, etc...is too long. I had to go through and remove about 15 albums and re-generate the .DB file over and over and over and over again until I could make it through without crashing.
Does your program support ID3v1 or v2 or both? Which would be more stable?
-
Here is an example of the .DB in question...I cut/pasted the last little bit. You can see how some tags are fine while others aren't so fine.... they all look perfect in a TAG editor.
-
Here is an example of the .DB in question...I cut/pasted the last little bit. You can see how some tags are fine while others aren't so fine.... they all look perfect in a TAG editor.
It looks like the tag editor isn't properly ending Unicode strings. My tag decoding is done by the official ID3 library code which is rather strict.
Regular strings are terminated with a 0; 16-bit Unicode strings are terminated by a pair of 0's. This looks like Unicode strings that have been terminated with a single 0. Unfortunately, the ID3 library expects correct Unicode and thus is not particularly tolerant of encoding errors.
Can you E-mail ZZTop's "I Need You Tonight" to celamantia@gmail.com? That track is off Eliminator; were the other tracks on that album ripped and/or tagged by the same software?
-
When i load the tags up in 3 different editors they all look fine. I am not sure which editor created that set of tags. When i get out to the juke I will send the tune over... if you can recommend an editor to use what would go in an re-tag all these somewhat easily, please let me know. I do believe MP3TAG is what I used but then I tried that TAGSCANNER software mentioned somewhere around here and it saw the tags as normal too...
-
When i load the tags up in 3 different editors they all look fine. I am not sure which editor created that set of tags. When i get out to the juke I will send the tune over... if you can recommend an editor to use what would go in an re-tag all these somewhat easily, please let me know. I do believe MP3TAG is what I used but then I tried that TAGSCANNER software mentioned somewhere around here and it saw the tags as normal too...
Well, if I can see the actual file I'll be able to stop guessing and know exactly what happened.
Can you send me one of the "good" files from the same album, too?
Thanks!
-
I just sent the first 4 songs from Eliminator to you in 4 separate emails (size limits and all).
Please let me know what you find out and if you have any suggestions how to fix it.
-
I just sent the first 4 songs from Eliminator to you in 4 separate emails (size limits and all).
Please let me know what you find out and if you have any suggestions how to fix it.
Hm. Comparing "I Need You Tonight" and "Got Me under Pressure", the part of the tag that includes the album name is identical (except for the last byte of the tag size field). So Unicode corruption can't be it. They should both be right or both be wrong.
The jukebox supports both V2 and V1. If both are present V2 wins.
-
I may try to go back to an older version of the jukebox software to create the DB file just to see...I don't remember it being this bad last time I regenerated the DB.
... and I did discard and regenerate a new DB yesterday just to make sure I wasn't going crazy.
-
Welp...I did a fresh install of the older version...
...same result. :(
Perhaps I should convert the tags all to ID3 v1 and try again?
-
In still pretty sure I'm correct, because I have fixed the extract same bug in my own software which was happens here. (aslo in MultiFE).... It's have detected the length of the unicode string 2 byte to much (but yours it might only been one) and then got some char garbage at end in the string. Due with the garbage, it would compare the strings difference and then split up the same albums.
If your debuffer output Utf8 and not unicode when using print, you would propenty see that problem.
Since it doesn't show that to the screen is because it got null terminated...
-
Is there something I can do on my end to stop this? Shorten the lengths of the names? Convert to ID3v1?
...or is it a bug that needs to be corrected by Chris? It would take me 30 hours to go through the .DB file and manually remove all the screw ups. I spent about 3 hours and only got to D!
-
Shorting the names dosent matter, if the is the tagfield length is detected few bytes to much. its a bug need to been fixed by Chris, but should been easy, since it only effect unicode field where it does it.
otherwice, If you split your collection up by this:
Artist/Album/Track - title.mp3
You can do that by using a tagger app, example by ID3-Tagit.DE or tagscanner, and then you dosent need to tag scan it all by WDJukebox and all coverats should show correctly and the database creation would been much faster. I simply guess you have tagged all your files, so you can do this automation.
-
...so should I start spending the countless hours it's going to take to remove all the errors from the .dat file manually or are you working on a fix Chris? ...and if you are, any ETA? I am trying to get the juke up and running correctly for a party I am throwing on Halloween.
Thanks!
-
Even if all your songs have the right ID tags, Wincab still occasionally corrupts them and spreads them to multiple CDs. I have had that happen a couple times.
-
I think Chris should fix that bug soon, and correct the unicode textfield length problem (I have same problem here).
Until then disable id3 scanning, and let it scan based on folders and files (it somewhere in jukebox.ini) with the file mask structor like that I descripted (not tested, but most app use that system). It faster too (due it dosent need to open the files to check tags).
-
I tried going by folder but it looked like ass...everthing came out as ARTIST: SINGLE and then broke down the album name with artist and album name in it which looked screwy.
I also tried to do a FIND/REPLACE in the .dat file and it worked for some characters, but others (like the square box character (null?)) doesn't work0...says it can't find those characters.
-
I wonder if your issue might be fixed by using mp3tag to display the tags and then save them again, using the option I discuss in this thread:
ID3V2.3 Mp3Tag set to ISO-8859-1 cures my bad tags (http://forum.arcadecontrols.com/index.php?topic=84719.msg891958#msg891958)
Brian
-
I'll try that.
-
I wonder if your issue might be fixed by using mp3tag to display the tags and then save them again, using the option I discuss in this thread:
ID3V2.3 Mp3Tag set to ISO-8859-1 cures my bad tags (http://forum.arcadecontrols.com/index.php?topic=84719.msg891958#msg891958)
Brian
I have one thing to say...
YOU ARE THE MAN!!!!!!!!!!!!!!!!!!!!
I changed all tags to ISO-8859-1 and sure as shiznit... it cleaned up 95% of the files!
There are a few that are still being classified as singles when they aren't, but it looks like only about an hours worth of work instead of dozens of hours!
Chris, you're going to want to mention this somewhere I do think.
Again, thank you Dermbrian!!!!!
-
:-). The otherway to convert Unicode to AscII, so it dosent show wrong. In some files it might still require Unicode, if they use other ISO charset, since I wont convert mine, so I can test until the bug is fixed.
About the singles it can been very defficent bug nothing with the unicode to due.
-
To be clear, converting fixed the issue. The only problems I have now are with tags that need fixing.
Thanks again!
-
I think I have fixed this issue; the fix will be in 3.2.1.