Audio Spectrum from Stereo to Mono

[KerimF]

by KerimF » Fri Feb 01, 2019 10:52 am
Attachments:
M_RoadToHell_ChrisRea1.wav(517.18 KiB)
S_RoadToHell_ChrisRea1.wav(1.13 MiB)

by KerimF » Fri Feb 01, 2019 1:55 pm

M(2x-1) = ( L(x) + R(x) ) / 2
M(2x) = ( R(x) + R(x+1) ) / 2

This will preserve the original audio file length. But, as I hope, it will preserve its contents better.

Lately, I try implementing the algorithm (stereo to mono above) on the stereo sample "S_RoadToHell_ChrisRea1.wav".
Due to the world's sanctions against the people I was born among, the last genuine PC complier I was able to buy is the C compiler of the BorlandC 3.1 package.

Using this C compiler for DOS, a simple exe could be created to convert a stereo wav file to mono if the format of the original wav file is well known.

By using the "Free Hex Editor Neo", I was able copying the raw file, as hex, to "Excel".
I noticed there are two headers; at the beginning and at the end. So my first step is isolating them from the 'audio' data block and searching, as possible, about the meaning of 'all' their various parts (I already know some of them).

From the top header, one audio sample is 32 bits (4 bytes). But I wonder if its format is 2's complement or float.

Thank you.

Kerim

[steve]

I noticed there are two headers; at the beginning and at the end. So my first step is isolating them from the 'audio' data block

In Audacity, if you Export as "RAW", then you get a file containing only the PCM audio data (same format as WAV, but without any headers).
"File > Export > Export Audio > Other uncompressed files"
See: https://manual.audacityteam.org/man/oth ... tions.html

[KerimF]

I noticed there are two headers; at the beginning and at the end. So my first step is isolating them from the 'audio' data block

In Audacity, if you Export as "RAW", then you get a file containing only the PCM audio data (same format as WAV, but without any headers).
"File > Export > Export Audio > Other uncompressed files"
See: https://manual.audacityteam.org/man/oth ... tions.html

Thank you, Steve, for mentioning the "RAW" option; I used focusing on "WAV" instead.

So, I run Audacity (2.3.0). And I chose 'Export Audio' on the 'Export Menu'. Then, I selected "Other uncompressed files" and "RAW (header-less) which give as 'Encoding' "VOX ADPCM".

Saving as "RAW" format, as expected, worked for the mono file "M_RoadToHell_ChrisRea1.wav", but not for "S_RoadToHell_ChrisRea1.wav".

Don't you agree with me?

Thank you.

Edit:
Sorry, I thought "VOX ADPCM" as 'Encoding' is the only choice. So even "S_RoadToHell_ChrisRea1.wav" could be saved without headers as 32-bit float.

[KerimF]

So far, while analysing S_RoadToHell_ChrisRea2.wav, I noticed that the length of the top header is 80 bytes (excluding the first 8 bytes).
And the length of the bottom one is 308 (starting with “LIST”).

To simplify a bit my work, I tried removing the latter header and adjust the file length (byte_4 to byte_7) accordingly (decreased by 308). The resulted wav file “S_RoadToHell_ChrisRea2.wav” looks good for Audacity.

Now, I have to also search about the Audacity “fact Chunk” in the top header. Searching the words “fact”, “chunk” and “data” on the ‘html’ help files didn’t help in giving information concerning the fields after the 4-byte word “fact” (in the header).
I wonder if there are other Audacity sources to search this info.

Thank you.
Kerim

[steve]

I don't think you need to manually fiddle with WAV headers. You could just export as RAW PCM, apply your program to the data producing a new RAW (data only) PCM file, then use "Import RAW" to get the data back into Audacity: https://manual.audacityteam.org/man/fil ... mport.html

Note that with "Import RAW" you will probably have to enter the format details manually. In the absence of file headers, it is often not possible for Audacity to guess the format.

[KerimF]

I don't think you need to manually fiddle with WAV headers. You could just export as RAW PCM, apply your program to the data producing a new RAW (data only) PCM file, then use "Import RAW" to get the data back into Audacity: https://manual.audacityteam.org/man/fil ... mport.html

Note that with "Import RAW" you will probably have to enter the format details manually. In the absence of file headers, it is often not possible for Audacity to guess the format.

Thank you.

Since the original wav samples are 32-bit float, I also searched this format.

So far, the best webpage, I found, is:
https://www.audiorecording.me/32-bit-fl ... guide.html

[steve]

32-bit float is very convenient for programming, as it's just one floating point number per audio sample. It's also very good for audio processing because it supports extremely high sound quality with a huge amount of "headroom".

The only really important downside is that sound cards don't directly support 32-bit float, so it has to be down-sampled to 8, 16 or 24 bit (integer) before it can be played. 16-bit is the most widely supported (as used on audio CDs).

[steve]

M1 = ( L1 + R1 ) / 2
M2 = ( R1 + L2 ) / 2
M3 = ( L2 + R2 ) / 2
M4 = ( R2 + R3 ) / 2
...
M(2x-1) = ( L(x) + R(x) ) / 2
M(2x) = ( R(x) + R(x+1) ) / 2
...
M(2n-1) = ( Ln + Rn ) / 2
M(2n) = Rn / 2

This will preserve the original audio file length.

I don't see how that preserves the original length.

Say you have a stereo track, with a sample rate of 44100 Hz, and a length of 1 second:
There will be 44100 samples in each channel.
For the final (nth) sample, n=44100, 2n=88200
so the mix has 88200 samples, which at a sample rate of 44100 = 2 seconds.

The mix 'could' have the same length if you also changed the sample rate to 88200 Hz, but that's not what you said.

Also, I don't see the pattern - did you mean:

M1 = ( L1 + R1 ) / 2
M2 = ( R1 + L2 ) / 2
M3 = ( L2 + R2 ) / 2
M4 = ( R2 + L3 ) / 2

If so, then that would be effectively the same as a normal mix, with intermediate samples placed between each sample of the mix, where the nth intermediate sample is (Ln+1 + Rn) / 2

If that's what you mean, then the effect would introduce high frequency noise, due to the offset between the intermediate samples and the interpolated value of the "true mix" samples.

[KerimF]

M1 = ( L1 + R1 ) / 2
M2 = ( R1 + L2 ) / 2
M3 = ( L2 + R2 ) / 2
M4 = ( R2 + R3 ) / 2
...
M(2x-1) = ( L(x) + R(x) ) / 2
M(2x) = ( R(x) + R(x+1) ) / 2
...
M(2n-1) = ( Ln + Rn ) / 2
M(2n) = Rn / 2

This will preserve the original audio file length.

I don't see how that preserves the original length.

Say you have a stereo track, with a sample rate of 44100 Hz, and a length of 1 second:
There will be 44100 samples in each channel.
For the final (nth) sample, n=44100, 2n=88200
so the mix has 88200 samples, which at a sample rate of 44100 = 2 seconds.

The mix 'could' have the same length if you also changed the sample rate to 88200 Hz, but that's not what you said.

Also, I don't see the pattern - did you mean:

M1 = ( L1 + R1 ) / 2
M2 = ( R1 + L2 ) / 2
M3 = ( L2 + R2 ) / 2
M4 = ( R2 + L3 ) / 2

If so, then that would be effectively the same as a normal mix, with intermediate samples placed between each sample of the mix, where the nth intermediate sample is (Ln+1 + Rn) / 2

If that's what you mean, then the effect would introduce high frequency noise, due to the offset between the intermediate samples and the interpolated value of the "true mix" samples.

You are right, Steve. Only now I noticed my mistake. The M samples are:

M1 = ( L1 + R1 ) / 2
M2 = ( R1 + L2 ) / 2
M3 = ( L2 + R2 ) / 2
M4 = ( R2 + L3 ) / 2 <<=== it was M4 = ( R2 + R3 ) / 2
...
For x=1 to n
M(2x-1) = ( L(x) + R(x) ) / 2
M(2x) = ( R(x) + L(x+1) ) / 2 <<=== it was M(2x) = ( R(x) + R(x+1) ) / 2
...
M(2n-1) = ( L(n) + R(n ) / 2
M(2n) = R(n) / 2

So L(1):L(n) and R(1):R(n) are converted to M(1):M(2n). In other words, no change in RAW length. Obviously, the new samples should be read as one channel and at twice the original speed/rate.

About introducing noise, I assumed that the conventional algorithm is simply:
M(x) = ( L(x) + R(x) ) / 2
So please let me know if this is not the case.

On my side I will also try comparing the 32-bit floats of the mono and stereo files to have an idea on how the conversion was done and reduced the stereo data size to half (for mono).

[KerimF]

The only really important downside is that sound cards don't directly support 32-bit float, so it has to be down-sampled to 8, 16 or 24 bit (integer) before it can be played.

I learn from this that if I export a wav file, that uses 32-bit float, using the 24-bit encoding, there will be no audible loss of any sort if played by the sound card of my lap.