Best way to encode mono CDs Options

[EmSiV]

Hi all! :-)

I'm trying to convert my opera collection in mp3. I have a lot of AAD, mono CDs... Actually, I'm ripping wavs with EAC, converting with lame (using all2lame) with these switches:

CODE

-V 0 --vbr-new -m m

This way, the encoder downmixes the stereo input and outputs a mono mp3 file.

Well... Is there a better way, without downmixing ? (i.e., ripping or encoding only the left - or only the right - channel).

Thank you!!

m.

[Societal Eclipse]

Under the Compression Options -> Waveform -> Sample Format you should be able to select 44.100khz 16bit mono. I'm not sure if that's a better choice than what you are doing now since I've never owned a mono CD.

[EmSiV]

Thank you. But I think this way will be the same

By now, the best way I've found is to rip wav with eac, then open it with a program like Audobe audition and save only the left channel as wav, then convert with the settings above...

[Societal Eclipse]

Since you have Audition have you tried subtracting one of the channels from the other to make sure they're the same?

[EmSiV]

Err... How?

[AndyH-ha]

There are a number of ways to look at this. One that I find most interesting is to run the Channel Mixer in single waveform view. The LR to Mid-Side preset will put the sum of the two channels in the left channel and the difference in the right channel. If the two channels are completely the same, the right channel will be digital silence. This is also one of several way to make a good mono track from a stereo source. You keep only the left channel.

This will often give a low level signal in the right channel that is either dither (which will never be the same in both channels if applied when in a two channel mode) or cross talk. Neither of these is a sign that the source track isn't really mono and fretting about it should begin. A true stereo track will generally have quite a bit of signal in the right channel, although the amount can vary quite markedly from moment to moment along the track.

[EmSiV]

Very useful, thank you

[NeoRenegade]

Best thing to do in this case would be to add -a to the commandline rather than -mm.

-mm sets the stereo mode to mono. -a downmixes to mono.

[EmSiV]

-m mode

[cut]

(m)ono - Input is encoded as a mono signal. If it is a stereo signal, it is downsampled to mono. The downmix is calculated as the sum of the left and right channel, attenuated by 6 dB.

-a

Downmix from the file from stereo to mono for mono encoding. The downmix is calculated as the sum of the left and right channel, attenuated by 6 dB as mentioned in the above example. This option is only needed in the case of raw PCM stereo input. This due to the fact that LAME cannot determine the number of channels in the input file. To encode a stereo PCM input file as mono, use the command: lame -m s -a.

For WAV and AIFF input files, using -m -I m always produces a mono .mp3 file from both mono and stereo input.

Seems to be the same (-mm or -m s -a)

[Cyaneyes]

Well... Is there a better way, without downmixing ?

I think the better way is not to worry about downmixing or making mono mp3s at all. You're using joint stereo in your encoding, which means LAME will be intelligent enough to recognize the mono nature of the audio and adjust bitrate accordingly. So you're not really saving space or quality by converting to mono, and could be causing issues with playback. (My M-Audio card plays back mono audio in the left channel only, for example.)

Don't mean to be a downer, but IMO it's not worth it at all.

[Slipstreem]

I agree with Cyaneyes totally.

Joint Stereo will encode a mono source down to about half the filesize of a stereo one with equal quality in VBR using LAME.

Any 'accidental' stereo signal that happens to be on the CD master of the original recording will remain intact. The MP3 will sound pretty much identical to the CD when played back on conventional stereo equipment, and play back perfectly on mono systems also.

I tried encoding a CD of old mono 1960s reggae recordings in both Mono and Joint Stereo VBR at -v2 settings and the Joint Stereo version blows the Mono one out of the water.

I suspect that it may have something to do with minor phase errors between the 2 'mono' channels that appeared somewhere down the line when the genuine single mono channel became two 'mono' ones. Doing a 'mono' downmix in software before/during encoding won't remove these errors and will possibly make things worse due to the samplerate swinging around in VBR mode. I don't think that the two channels are, technically speaking, summed. Not in the same realtime domain way that a mono button on an amplifier does anyway.

Please correct me if I'm wrong on this last point, as I'm still a noob around here. LOL

Spooky isn't it, but it seems that the LAME MP3 encoder knows instinctively what to do under these circumstances where 'mono' signals appear if JS is selected as your default. Who's a clever encoder!?!?

Cheers, Slipstreem.

This post has been edited by Slipstreem: Jul 9 2006, 15:45

[EmSiV]

You're theorically right.

Here are the results of the conversion of a track on a mono marked CD (Label: Decca)

Duration: 4m34s

-V0 --vbr-new -mm (mono)

Dimension: 4,26 MB
Av. Bitrate: 89 Kbit (VBR)

-V0 --vbr-new (Joint Stereo)

Dimension: 6,69 MB
Av. Bitrate: 139 Kbit (VBR)

So I have to suppose the CD is not really mono?

Well, I've taken a mono wave file, duplicated the mono channel to obtain a stereo file, and then converted it.

Duration: 2m09s

-V0 --vbr-new -mm (mono)

Dimension: 1,71 MB
Av. Bitrate: 111 Kbit (VBR)

-V0 --vbr-new (Joint Stereo)

Dimension: 2,12 MB
Av. Bitrate: 138 Kbit (VBR)

Your move

This post has been edited by EmSiV: Jul 11 2006, 11:16

[Cyaneyes]

Your move

Interesting.. what version of LAME was this? I'll do a couple tests myself.

[EmSiV]

LAME 3.97 b2

[dv1989]

I would use joint stereo. You won't be losing too much as the files are "close to" mono, but you lower the risk of running into artefacts such as those already mentioned.

[EmSiV]

That are veeery old (30's, 40's), low quality remastered records, so I think I cannot obtain "real" advantage by using joint stereo instead of a downmixed mono.

But the question is interesting anyway

[Cyaneyes]

Using 3.97b2, -V 2 --vbr-new, I got 104.2 kbps for a mono wav and 124.0 kbps for the "duplicated stereo" version of the same. I would have thought it would have been a bit more efficient.

For comparison, a lossless encode of the same track (Optimfrog 4.520b, default) results in 459 kbps for the mono track and 462 kbps for the duplicated stereo.

This post has been edited by Cyaneyes: Jul 11 2006, 13:47

[Slipstreem]

Hi Cyaneyes. :-)

Going on your first bunch of figures, that makes the process around 70% efficient (I think?).

Maybe the bits that represent the other 30% is where the perceived improvement in quality comes from in JS mode.

Never mind. I won't lose any sleep over it. JS always sounds mighty fine to me!

Cheers, Slipstreem.

[2Bdecided]

I'm re-visiting this issue myself.

Lame 3.97 --preset standard uses 10-30% fewer bits encoding a mono file than a dual mono file of exactly the same content.

What's interesting is that those extra bits aren't being "thrown away" - the quantisation noise on the dual mono (higher bitrate) file is lower than on the single channel mono file (as seen via inverse mix pasting the original over the encoded version in Cool Edit).

Or, to put it another way, the lower bitrate on the mono file isn't (just) due to greater efficiency - there's actually more real information being thrown away. Whether this info is audible or not is an interesting question!

I will probably re-test this on something tricky which I can ABX, but even this "objective" (and subjectively meaningless!) measure is interesting, because if you trust the psy model when running in stereo, it implies that the psy model is being too agressive when running in mono.

Or, conversely, if you think the psy model is correct in mono, then it must be wasting bits in stereo.

If stereo wastes bits, that's a shame - but if mono is actually too aggressive, then that means that, in theory, a mono file should be converted to dual-mono and encoded (in joint stereo) to hit regular "--preset standard" kind of quality. Anyone encoding mono in mono is getting lower quality than they expect.


I've found interesting effects, beyond this, with CD rips of actual "mono" recordings (i.e. one that should be mono but aren't bit identical).

On one track, where the music is perfectly mono, but there's stereo noise shaped dither on top, that dither adds an extra 10kbps (~9%) compared with dual-mono (generated by duplicating one channel to two).

On another, where the source is a mono tape played in stereo, and the difference channel is comparatively noisy (~30dB down typically) this still only adds 11.5kbps (~8%) compared with dual-mono. I thought it would be more, but the track is more complex so the btirate is already higher. On this track, going from "stereo" to single channel mono reduces the bitrate from 146kbps to 109.6kbps.

Just got to figure out if 146kbps is overkill, or 109.6kbps is too low.

Those of you with one or two mono tracks on one CD somewhere probably won't care - but some of us have hours of mono recordings to encode!

Cheers,
David.

[Gabriel]

This is because Lame is too safe with dual mono content.
There is a safety used by Lame, which prevent a full starving of the side channel. Obviously, in the case of identical content on left and right, side channel should theorically be totally empty, but Lame, because of this safety, wastes bits there.

A side effect is that when you have some content in the side channel (ie both channels are not bit for bit identical), Lame is then likely to encode the side channel using more bits than what is determined to be needed by the psy model. This might lead to higher actual quality than the target quality of the used vbr level.

This means that for single channel content, you will have the same quality level as an "usual" stereo content, while for near mono content, you could have an higher quality level than an "usual" stereo content.
All this is just a side effect.

I agree that in this case, Lame is a bit inneficient, but until now we did not considered it to be a priority. With plain stereo content it's very rare, and with near mono content, users are usually not complaining as they already have a lower bitrate than with regular content.

[2Bdecided]

Thanks for that Gabriel.

I didn't include the side channel in this comparison. It's silent both before and after encoding (though I understand what you're saying - lame could be using some bits to encode that silence, and lots of bits to encode near-silence on a nearly-mono source).

The thing is with a genuine bit-identical dual-mono recording, it doesn't seem that all of those extra bits are going on the side channel. I used an invert mix paste to extract the quantisation noise, and this consistently shows a few dB more noise in the mono version than the dual mono version.

As you can imagine, the difference changes dynamically, ranging from noting to ~10dB. 3-6dB seems typical. On "problem samples" where lame is throwing more bits at both versions, I've seen the difference consistently as low as 1dB.


So is there something else going on other than the "don't starve the side channel" mechanism? Are any different processes applied to the M of an M/S encoding than to the M of a single channel encoding?

Cheers,
David.

P.S. (EDIT) No ABX. I can't find a mono sample that --preset standard has problems with either way. This is just about bitrate, and understanding what's actually happening.

This post has been edited by 2Bdecided: Feb 22 2007, 12:24

[Gabriel]

Let's consider the case of bit identical dual mono.

Theorically, it should give you the same quantization noise in "stereo" and mono.
Bits distribution can be checked on an already encoded file using Mp3X (http://gabriel.mp3-tech.org/lame/), the graphical frame analyser. Using it, we should be able to track where are the extra bits.

Could you post a small source sample file, that once encoded significantly exhibit this behaviour?

Regarding what is exactly happening, it might be possible that there is a level calibration error somewhere, as mid channel in mp3 is (l+r)/sqrt(2) and not (l+r)/2, but this is pure speculation.

[2Bdecided]

I've downloaded Mp3x and the dlls and, despite some errors in the command window, it seems to work for most of the plots.

Comparing mono with dual mono...

I can see differences, but can't interpret them.

One stuck out: the global gain's don't match.

Also MDCT 0 and 1 bits are consistently higher for dual mono on most (not all) frames.


I've attached a mono file. The mono/dual mono difference isn't so great on the extract as the full track (which gives mono: 109.6kbps, dual mono: 134.5kbps), but it's still significant and useful for testing. On the extract, the quantisation noise is about 4.5dB louder in the mono version than in the dual mono version.

There's nothing special about this sample at all. It's just the left channel from the CD.

I've also attached the dual mono version so you can check that I (and Cool Edit Pro) are not messing this up - it's the first thing I'd check if I were you, though of course I've already checked it myself!

Hope this helps.

Cheers,
David.

Attached File(s)

 001__08__Help_Me_Rhonda___Beach_Boys_cut___mono.flac ( 620.79K ) Number of downloads: 80
 001__08__Help_Me_Rhonda___Beach_Boys_cut___dual_mono.flac ( 621.08K ) Number of downloads: 246

 

[2Bdecided]

Another thing...

I don't claim to understand Mp3x, but it did seem to be telling me that no bits were allocated to the side channel - or at least to the things that were actually being plotted - as I mentioned, I'm getting some plotting errors here, so could easily be missing something.

Cheers,
David.

[2Bdecided]

I don't suppose one of our resident golden ears can try a test of this?

Take a problem sample.
Make a mono version.
Make a dual mono version.
Encode both.
See if there's a big bitrate difference between the two.
ABX them.

I'm failing on that last step!

Cheers,
David.