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: MAD vs Foobar - problem sample (Read 5836 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MAD vs Foobar - problem sample

I don't even have to do a proper ABX test - I can hear it every time, and so can you. The source is a low quality mp3, but regardless - MAD is less offensive.

I first heard the difference using Winamp 2.91 with the MAD 0.14.2b plugin. I then used the latest MADPLAY (MAD 0.15) as a disk-writing tool. The version of Foobar2000 was 0.7.2.

MAD vs Foobar - problem sample

Reply #1 –
The file labeled FB2K.wav appears to have severe dropouts in the right channel, which start from about 4 kHz and go all the way up to 16 kHz (the mp3 cutoff frequency).  Can you supply the mp3 as well?  I would try decoding with lame (lame --decode).  This should decode properly and should be audibly indistinguishable from one of the two.

BTW, it looks like FB2K is doing some sort of noise-shaped dither.

ff123

MAD vs Foobar - problem sample

Reply #2 –
I don't know about the legality of providing the full mp3? What approach do you suggest? Could I perhaps use mp3trim or something similar?

Yes, Foobar had strong ATH noise shaped dither enabled for the disk-write. MAD is doing its own form (triangular?) of dither. It doesn't make any difference when it comes to the problem at hand. When I spotted the problem both MAD and Foobar was set to 32-bit undithered output.

MAD vs Foobar - problem sample

Reply #3 –
Must be intensity stereo, it's been broken in mpglib all the way along, I found this problem a while ago on different samples; I'll look into fixing it, but it's low priority now (perhaps I'll use ACM codec or something like that for MPEG-2 layer 3 instead, because mpglib has other funny issues there).
On a side note, it's rather hard to correct this problem because MPEG forgot to provide reference decoder that passes their own conformance tests on intensity stereo - seems like intensity stereo code in their reference decoder was a subject of many bugfixes recently, but last time I checked a compile of their own decoder failed the conformance test (and so did all other decoders I tried, including MAD and FhG ones, older FhG ACM even crashed on one of samples).
For those interested, this problem can't possibly affect files encoded with LAME, because LAME doesn't even support intensity stereo.
[edit: corrected wrong info about 44.1khz]
Microsoft Windows: We can't script here, this is bat country.

MAD vs Foobar - problem sample

Reply #4 –
I wouldn't expect a low-bitrate file to have a cutoff as high as 16 kHz, but that's why a sample of the mp3 would be useful to inspect.

ff123

MAD vs Foobar - problem sample

Reply #5 –
Indeed, just finished downloading it, but these samples are useless without original file exposing the problem in the decoder. I'm working on an option to use FhG ACM for decoder anyway.
Microsoft Windows: We can't script here, this is bat country.

MAD vs Foobar - problem sample

Reply #6 –
Ok, here is the relevant part of the original mp3.
 

MAD vs Foobar - problem sample

Reply #7 –
OK, this is interesting, it's not even intensity stereo, must be some new mpglib bug, thanks for your input.
(Original intensity stereo glitch couldn't possibly affect 44.1khz files)
Microsoft Windows: We can't script here, this is bat country.

MAD vs Foobar - problem sample

Reply #8 –
OK, I apparently broke it when trying to fix intensity stereo problem in 0.7.
Fixed version of foo_input_std.dll uploaded here.
Microsoft Windows: We can't script here, this is bat country.

MAD vs Foobar - problem sample

Reply #9 –
Quote
OK, I apparently broke it when trying to fix intensity stereo problem in 0.7.
Fixed version of foo_input_std.dll uploaded here.

Should we replace the .dll currently in 0.7.2?
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

MAD vs Foobar - problem sample

Reply #10 –
You can rename the old dll to "foo_input_std.dll.bak" and copy the new one into the folder. If you get problems you can always switch back. (But probably you want an official statement by zZzZzZz and you already know this "trick")
To be on the safe side just wait for the next release! I have no problems with this new standard input.

Regards,
The Link