Version: 1.4-SVN (using KDE KDE 3.5.2) Installed from: Ubuntu Packages OS: Linux For some strange reason, all the old low-bitrate mp3 files (128kbps and below) are now screwed up and sound all jumpy with clicks like a scratched cd or something. The files are on 3 different hard drives and they are all screwed up in the same way. The newer files (on same drives), that had proper tags and were 192kbps or higher bitrate are ok. Last modification time on all screwed up files is July 25th (that's about when first ATF enabled svn builds of amarok started to appear, iirc). Of course I'm not 100% sure that it was amarok that killed the files, but it was about the only thing that was doing anything with those files while they were open in write mode, and i dunno what else that might have been. A link to a sample screwed up file: http://l3ech.net/Squarepusher_-_Drum_and_Bass_2000.mp3 Please let me know if that was indeed amarok that done that, and is there anything that can be done to fix that.
I can hear the pops and clicks in the test file. The possibility that Amarok did that (or more specifically that TagLib did it) is slim, but theoretically could happen. Normally those pops are due to the encoder, and normally when writing the ID3v2 tags, the actual song data is not changed. In some cases if there is not enough padding at the front of the file for the ID3v2 tag, padding is created, which involves a rewrite of the file. This should be an error-free operation, as it's simply writing a bunch of zeros, then copying the old song data over verbatim. What would be very helpful would be a before-n-after...if you can get one of those files encoded in the same way (for instance, maybe it only affected your low-bitrate files because they are the only ones that didn't have padding or something), keep a copy of the original, and see if applying the ATF tags to it causes the problem, and then link to both, it would help immensely.
Seems related to reports of MP3 corruption on Bug 131353
I think you may be right about the padding thing... I also noticed that some of the higher bitrate files were affected by that bug, less jumps though, and most of the broken files had no ID3v2 tags at all. It's possible that this bug was already fixed, might have been one of those SVN-only bugs... I have some of the broken files on backup cds, but some files are not in backups and I would still like to know if there's a way to restore them from broken state. Here is a before-after example (from backups): Before http://l3ech.net/Primal_Scream_-_Vanishing_Point_-_05_-_If_They_Move,_Kill_'em.mp3 After http://l3ech.net/Primal_Scream_-_Vanishing_Point_-_05_-_If_They_Move,_Kill_'em-BROKEN.mp3
I'll look at this file. At the moment, there's another piece of information I need to know from you: can you consistently reproduce this? i.e. if you take (a copy of) the good file above, and try adding the ATF tag again, can you reproduce the broken file? As long as you have ATF tag writing turned on, you can do this easily without needing to do an entire collection rescan by using the dcop call dcop amarok collection newUniqueIdForFile <*full* path to file> Having been looking at the relevant taglib code my guess is that you can't...but we'll see if I'm right :-)
I already tried reproducing it and it doesn't reproduce. That's why I said that it's probably already fixed... Tried what you said (newUniqueIdForFile) with a current SVN version... File changed but it's not the same as the broken file (that amarok from Jul-25th broke), and it sounds ok.
Nothing has been changed in Amarok that would cause this to work one time and not another. Although there have been some changes in TagLib they shouldn't affect this. Since getting this report, and a report from two or three other people who complained of the odd MP3 file getting pops and clicks, I've closely scrutinized the code in taglib that reserves space for ID3 tags, and have been talking with the taglib author. I do have a possible answer for you, although you probably won't like it, as it has nothing to do with taglib or amarok. However, I'd like you to do something first. Please post the above file in a working, but ATF-tagged state. There is an oddity in the file, in that it contains two subsequent tags. I'd like to see if that's the case with the non-screwed up but ATF tagged version, as it may give a clue as to where to look in taglib if something's wonky with it. Oh, two more things. First, can you tell me how many MP3s you tagged with ATF tags, and an estimation of how many were screwed up? Second, do you find that programs (or your computer) crash or behave weirdly more often than you might think they should?...or does anything else about your computer's behavior ever seem odd?
Okay, more for you to do. If you have more of the broken files, please try opening them in e.g. khexedit. At the very top you should see ID3, which is the start of the ID3v2 tag. Both of your messed up files contain two subsequent ID3v2 tags, which is very odd. Can you look at, say, ten of your other messed up MP3 files, and ten non-messed-up -but-ATF-tagged MP3 files, and tell me how many of each contain two subsequent ID3v2 tags? Thanks!
Another thing...with your before-and-after files, your "before" file had only an ID3v1 tag, not a ID3v2 tag. Can you tell me whether this was true for all of the files that were messed up? Thanks!
Could it happen that the same file was written to several times at once? E.g. 2 collection scanners running at the same time or a collection scanner and amarokapp because of adding the file to the playlist? (The last scenario should not happen anymore, but the first is still valid, I think.)
That is what I'm thinking...that there were two writes. This could also explain the OGG behavior. In addition this could explain why this behavior suddenly stopped -- it could have stopped when we made the (good) decision to, for stability's sake, only allow ATF tags to be written by the collection scanner or by an explicit DCOP call. We could further enhance this by using a mutex, although I'm not sure how mutexes behave across two processes...any thoughts on that, Martin?
It appears to be that all broken files indeed have two subsequent ID3v2 tags, and before they didn't have ID3v2 tag, only ID3v1 tag or no tag at all. Non-broken files have one ID3v2 tag. Probably was an amarok that crashed while it was rescanning collection and another one was started and it rescanned the whole collection while a collection scanner from a crashed amarok was still running... So, mp3check of the broken files gives out a lot of "frame too long/frame too short, skipping N bytes" errors. I compared a broken file (after manually removing the first ID3v2 tag with a hex editor) with proper ATF tagged file (which was the exact same size in bytes as the manually edited broken file with 1 tag removed) in a binary diff util and it seems that the files are mostly the same, but are totally different in random places without any pattern obvious to me... Here's a proper ATF tagged file to match the before-after example from above: http://l3ech.net/Primal_Scream_-_Vanishing_Point_-_05_-_If_They_Move,_Kill_'em-WORKING-ATF.mp3 Is there a way to run something to automatically identify all files with two subsequent tags? Manually checking a 300GB collection would take forever and it seems that a lot got screwed, can't even say how much...
This has now been confirmed as the same problem as bug 131353, marking it as such. *** This bug has been marked as a duplicate of 131353 ***