Listen to the songs on another computer, maybe it's just a software error
Try scanning the files with mp3utility for instance. If there is anything wrong with the files mp3utility should detect that.
The obvious cause for this would be a bad rip... how are you sure that it wasn't there before
Try playing it in foobar (reports errors in console AFAIK).
(I only refer to one file, as I deleted the others already, gonna get them back flawlessy)I experience the same click when playing on another machinefoobar detects clipping in the song, but otherwise no errors accured.that clipping couldn't be the source of the corruption I guess, because heavy audible distortions just appeared now and weren't there before... does someone can suggest further steps to take in order to find the reason for this realy odd stuff? ta.
QuoteTry scanning the files with mp3utility for instance. If there is anything wrong with the files mp3utility should detect that.shoudn't they then have been sounded crap from the first moment on? I'll do it anyway.
Try scanning the files with mp3utility for instance. If there is anything wrong with the files mp3utility should detect that. If it doesn't it is probably something else that is wrong
@ Snelg: email sent, thx for the support.
Whether they say "File(s) = Good" or "File(s) = Not Good" will not change the fact they sound crappy.So, have you re-ripped any yet? Do they still feature loud clicks?
It's not a problem caused by MP3Gain. The rare bug I mentioned produces loud clicks where there should be absolute silence.
But if you're 100% certain that the problem appeared recently...
then my second guess would be that somehow you used a program that cleanly snipped a frame or two out of the middle of the mp3
I recommend that you use fsum or similar to calculate md5 checksums of your files. That way you will now for sure if the data is changed.
QuoteI recommend that you use fsum or similar to calculate md5 checksums of your files. That way you will now for sure if the data is changed.uah, command line utility *shiver* forgive me my ignorance, but did I get it right that the tool checks if the data has changed from timestamp a to timestamp b?if this is the case, then it would be useless, as the data (according to me) has already changed... timestamp a would thus be after the corruption and the app would not reveal any changes. please correct me if I'm wrong.anyway, I tried the tool (I hope I did it right...) and no errors were found.
However, generating MD5 sums for the files you already know have been corrupted is a useless task
Another option is the use of parity files
Even today I wonder what the hell happened on that day. I was pretty pissed off to my friend for some time, because I naturally blamed his HDD for the incident.Maybe something similar has happened to you too
but do you think that kind of errors described by me could be caused by bad ram?
Yes, operations that include rewriting the file (e.g. updating an ID3v2 tag), could damafe the file when the RAM is bad.