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: A new LAME problem sample (Read 6466 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

 

A new LAME problem sample

Reply #1
Oh, I see, you have to post in the Uploads forum to make attachments. Please excuse me, Alex B, I will post my samples here too, relevant to the same discussion we are having in the thread you linked.

Here is the 5-second sample clip, where a clear difference (I think, others can try to ABX for themselves) can be heard between LAME's Forced Joint-Stereo version and the original WAV file. Commandline used was LAME 3.95 -m f -b 192. Also, no problem were heard with LAME's normal Joint-Stereo implementation (switching, not forced) or Fraunhofer (l3enc) 192 kbps Forced Joint-Stereo (file not provided, make for yourself sorry).

I don't think there is anything special about this clip, probably the phenomena is global to most songs when LAME Forced Joint-Stereo is used (therefore, LAME Forced Joint-Stereo is very bad...should never use except to test). The only thing this clip shows is that LAME Forced Joint-Stereo implementation is very aggressive and starves the S-channel of bits....perhaps it also indirectly shows that LAME starves the S-channel of bits in normal Joint-Stereo during the times it selects to use M/S frames.

The obvious thing to notice is that the high-freq drums/puffs that come out of the pure Left channel in the WAV seem to come out quite close to the Center, in the Forced Joint-Stereo version. This can be seen on a spectrum analyzer or heard in a listening test, whichever you prefer. When I listened, the first "puff" also seems to come out of the Center a bit moreso than the later puffs which move over to the Left a little more (as the other sounds in the song become less loud afterwards, presumably LAME's S-channel finds it easier to encode).

A new LAME problem sample

Reply #2
Oh, I see, you have to post in the Uploads forum to make attachments. Please excuse me, Alex B, I will post my samples here too, relevant to the same discussion we are having in the thread you linked.  ...

Thanks, I'll try the sample and comment on it later (It may take a day or two before I have time examine it.)

BTW, you may want to to compress the wave samples with a lossless codec before uploading since the upload space is limited and you should not remove an uploaded sample too quickly (preferably only after the discussion about it has ended).

The most popular lossless codecs here seem to be WavPack and FLAC, which can be easily decompressed on various OS's. I have used WavPack.

Here are the MP3 samples that I used in my test. You may want to try them and compare them with the original and with a version that you encode with LAME 3.95 and your usual settings.

JS: [attachment=3139:attachment]
MS: [attachment=3140:attachment]

A new LAME problem sample

Reply #3
I listened carefully to all 3 samples you provided. I do notice a difference but don't feel it is extremely bad or anything. I haven't listened to the famous 'problem samples' before, so I don't know if this case is as bad as them or not. In the 3.6 to 4.6 second passage you mentioned as being extra offending (which I agree with you) I notice that LAME is often only using 112-128 kbps, which is a fairly low bitrate. I think the problem here is just a lack of bits. I tried encoding the original file you provided as 320 kbps cbr and to me it sounds indistinguishable from the original. I also tried 192 kbps cbr and thought it sounded okay, too.

Regarding why your Joint-Stereo version sounds better than the Forced-Stereo version (I'm not sure I could say which is better myself, but I'm happy to concur with your observations and tests) that doesn't surprise me either. Your 2 files are almost the exact same size, and as of late I think that LAME's VBR has a fundamental problem where it overcodes the M channel in M/S representation, giving it 20% more bits than it deserves...compared to the times when LAME chooses L/R representation. In theory VBR should try to maintain an 'equal perceived audio quality' at all times whether currently in M/S or L/R mode, but I think LAME VBR fails to do that.