Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: decoding offsets & wave compare util (Read 3330 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

decoding offsets & wave compare util

Decoding the same .mp3 with lame, cdex and winamp gives different size .wav files (with lame's decode being the smallest).

I can't hear any difference between the .wav's, and I take it the difference might have to do with lame's info line "skipping initial 1105 samples (encoder+decoder delay)".

Now the question... Using a wave-compare utility (WAVComp from http://players.shoutclub.com/wavdownload/), the lame decode appears to be best "synchronized" with the original. Meaning that after encoding a .wav to .mp3 and then decoding it back with lame --decode, WAVCompare reports 250 "error mean bits". Comparing the .wav decoded by winamp gives 4000 error mean bits - problem being that WAVComp does a brute sample-by-sample compare from time 0 on.

Does anybody know of a smarter wave-compare able to detect slight time-shifts between two .wav files and find a "best fit" before comparing?


P.S. This is just lab work, please don't flame about the pointlessness of comparing .wav bits.

decoding offsets & wave compare util

Reply #1
Perhaps this site might give you some useful information:

http://privatewww.essex.ac.uk/~djmrob/mp3decoders/index.html

Daffy

Edit:  Oops...sorry if this doesn't answer your question about a .wav compare utility.....I just thought you might be interested in these decoder tests

decoding offsets & wave compare util

Reply #2
This doesn't answer my question, indeed - all 3 of them (lame, cdex, winamp) have perfect scores there ;-)  Thanks for the pointer, anyway.

And, yes, forgot to mention... I tried EAC's wave-compare function but it reports the whole .wav's as different - which is correct, but doesn't help, either.