Hello,

I've done a small amount of development work with MP3 files in C++, namely parsing MP3 frame headers and merging multiple MP3 files together on a frame basis.

Now I've been asked if it is possible to convert a monaural file to stereo without having to decode/reencode. The conversion is needed to allow merging of monaural and stereo files into a single stereo file.

I've spent a couple of hours searching the net and haven't found an example of someone else already doing this. However, I did learn enough about joint stereo to believe it may be possible using M/S and specifying a flat side channel. I believe that qualifies me as being "smart enough to be dangerous".

I will be most grateful if anyone can provide an opinion on this and especially any existing links to articles or code demonstrating the process.

Thanks so much,

Tommy Baggett

Anybody?

I'll be the first to admit that I've only done MP3 work at the frame level, meaning that I understand the frame headers and how to cut and merge but I haven't done anything with the actual audio data. So perhaps I'm asking something that makes it obvious I don't know what I'm talking about.

Regardless, I'm trying to avoid spending hours (days?) learning how to manipulate the Huffman-encoded data and the whole mid/side joint stereo encoding technique only to discover it is a wasted effort because what I'm trying to do (lossless conversion) isn't possible. Whew! That was a mouthful.

So, again, is it possible to take a currently-mono-encoded MP3 frame, copy the Huffman-encoded data verbatim as the Middle channel and create a flat zero Side channel to convert it to a joint stereo MP3 frame?

Thanks again for any help provided!

TommyB

I think something along the opposite lines came up before for losslessly extracting the mono from a stereo file. That was definitely a tough one. I nearly replied to you before, but my knowledge is poor here. What it the purpose, anyway? It doesn't seem like you're gaining anything.

You might want to check out the mp3 repacker threads. If source code is available it might help, because it's all about losslessly shaving a few bits by unpacking frame data, shuffling bit reservoir and converting CBR to VBR etc (or vice versa) and deleting zero-padding in CBR files, then repacking as valid MP3 frames. It might make it a bit less painful for you to experiment if you can use snippets of open source code.

Thanks Dynamic! That's just the kind of tip I was looking for, at least short of a definitive answer. I would've never thought of searching for "repacker".


The intent is to convert a mono file to joint stereo so that it can then be merged with other joint stereo files into a single joint stereo MP3 file.

AFAIK, you can't change the channel mode within a single MP3 file. I won't need the mono to JS conversion if you can.

Yes, I think it should be possible this way.

You need to write modified frame headers (joint-stereo, M/S only) and add the necessary side_info structures for a second channel to the frames. Those added side_infos should be set properly to tell the decoder that there are no Huffman bits to be decoded for the side channel, resulting in all zero samples.
Unfortunately, the added side_infos increase the size of the frames. You have to inflate some or all frames to some higher bitrate stetting (header info) and adjust the position of the coded audio data (bit reservoir) accordingly. This bit reservoir shuffling will make the program more complex then it should be at first glance.

As Dynamic has already mentioned, Omions mp3packer can do lossless manipulations of mp3 files. Have a look at that source code. Maybe the easiest way to get it working is to add your "mono-to-mid/side" conversion as a new option to mp3packer?


The resulting JS file will be decoded at a lower amplitude than the original mono file because of the Mid/Side to Left/Right conversion performed by the mp3 decoder:
Left = (Mid + Side) / sqrt(2)
Right = (Mid - Side) / sqrt(2)
In the case of a converted mono file we have Mid=Mono and Side=0, so Left = Right = Mono / sqrt(2).
Not a big issue I suppose. It might be possible to compensate for this by adjusting the global_gain values of the JS frames. (see mp3gain sources for details)