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
Jul 7 2006, 18:22
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.
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
Jul 8 2006, 05:41
Since you have Audition have you tried subtracting one of the channels from the other to make sure they're the same?
Err... How?
AndyH-ha
Jul 8 2006, 12:26
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.
Very useful, thank you
NeoRenegade
Jul 9 2006, 05:37
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.
QUOTE
-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
Jul 9 2006, 07:22
QUOTE(EmSiV @ Jul 7 2006, 20:05)

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
Jul 9 2006, 08:32
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.
You're theorically right.
Here are the results of the conversion of a track on a mono marked CD (Label: Decca)
QUOTE
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.
QUOTE
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
Cyaneyes
Jul 11 2006, 06:06
QUOTE(EmSiV @ Jul 11 2006, 06:11)

Your move

Interesting.. what version of LAME was this? I'll do a couple tests myself.
dv1989
Jul 11 2006, 06:15
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.
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
Jul 11 2006, 06:45
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.
Slipstreem
Jul 11 2006, 08:23
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
Feb 21 2007, 09:12
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
Feb 21 2007, 16:46
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
Feb 22 2007, 05:21
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.
Gabriel
Feb 22 2007, 06:00
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
Feb 22 2007, 10:46
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.
2Bdecided
Feb 23 2007, 03:41
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
Feb 26 2007, 08:23
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.
2Bdecided
Feb 28 2007, 10:39
Gabriel has suggested ABX results are probably not very useful, since whatever is happening in the code needs to be understood, audible or not.
Unfortunately, I couldn't resist playing. My inability to easily ABx any of the mono samples lead me to create a kind of torture test for mp3 (attached) though lame 3.97 does very well with it.
I managed a kind of a result:
lame397 -V 9 --vbr-new
gives an audible difference. It's the mono version that sounds close to the stereo version - the dual mono version sounds different (pre-echo slightly more controlled). It's not fair to judge on one sample though.
However, the really strange thing is that
lame397 -V 6 --vbr-new
Reverses the bitrate difference! The mono version comes out at 284.6kbps, while the dual mono version (less efficient up until now!) come out at 193.8kbps. (The stereo version is 314.9kbps). I can't really hear a significant difference between them (the two mono encodings, that is - obviously the stereo one sounds different).
So it's not a hard and fast rule that mono gives a lower bitrate than dual-mono, though this is an extreme example.
Cheers,
David.
The Sheep of DEATH
Feb 28 2007, 11:29
QUOTE
However, the really strange thing is that
lame397 -V 6 --vbr-new
Reverses the bitrate difference! The mono version comes out at 284.6kbps, while the dual mono version (less efficient up until now!) come out at 193.8kbps.
That's astounding. What happened to the "safety margin?" Do the files analyse in the same way? Are you sure both channels in the original were identical (and that one wasn't, say, silent)?
2Bdecided
Feb 28 2007, 11:33
I'm sure, but at 4.61kB zipped anyone can easily download it and check.
Cheers,
David.
Gabriel
Mar 1 2007, 00:51
Just wanted to add that the bitrate increase of dual mono is not because of the side channel "safety belt". In those cases the side channel is allocated 0 bits.
Something else to find...
2Bdecided
Apr 24 2007, 08:30
From this thread...
http://www.hydrogenaudio.org/forums/index....showtopic=54421...it seems that dual mono encoded as mono is (more or less) identical to dual mono encoded as discrete stereo.
In other words, it's dual mono encoded as
joint stereo which is the "odd one out", not the mono encoding.
I can understand why the "M" channel of M/S might be given slightly more bits than the "M" channel of mono, or the L or R channels of L/R: The "M" channel of M/S will be added to "S" to create two channels, and as such there might be some unmasking which needs to be compensated for.
However, if the S channel = 0 then there can't be any unmasking, so it seems sensible to make the "M" channel of M/S identical to the M channel of mono in this specific circumstance. Also, if the "M" channel is intentionally "over coded", it's not by very much, so maybe it is not intentional but accidental.
Cheers,
David.
grombulk
Apr 24 2007, 10:01
QUOTE(EmSiV @ Jul 8 2006, 02:05)

Hi all! :-)
CODE
-V 0 --vbr-new -m m
This way, the encoder downmixes the stereo input and outputs a mono mp3 file.
Just to add to the confusion.
Foobar2000 doesn't play mono mp3's if you use Kernel Streaming or Asio as output.
At least that is what I discovered.
ymmv
Gabriel
Apr 24 2007, 10:12
I think that David put me on the right track with his last post:
In mp3, mid channel is defined as (l+r)/sqrt(2).
Lame has no specific provision to overcode mid channel, but consider mid in the same way as a regular (l/r) channel. However, this sqrt(2) factor provides an implicit overcoding of the mid channel.
In the case of dual-mono input, we have l channel identiqual to r channel. It means that we have mid channel equal to l*sqrt(2), this the noticed overcoding.
As pointed by David, although this overcoding is usefull on regular stereo, it's useless if there is no side channel.
Side note: if I had time I woulc check the mid channel overcoding, as it seems to me that right now the overcoding is only provided by a shift against the ATH, while it would be better the adjust the whole masking values.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.