AAC stereo vs AAC mono

[elmuz]

Hi all,
I did a test to prove a quite simple fact. With lower birates, is better coding a mono track instead of stereo one...
So I did a test using neroAacEnc.exe.

First of all I took a sample mono wave/pcm file "mono.wav", then I doubled in two twin track (L+R) and I saved as "stereo.wav".

Then I coded both file with neroAacEnc.exe with this string "-cbr 64000" ...it outputed two files, automatically coding in mono or stereo track looking into the source's properties.

What is strange is that the stereo one is better than the mono one. In your opinion why?
Did I miss anything? I attached all the samples...

[Hoser Rob]

Why is mono better with lower bit rate? That hardly seems a "simple fact" to me. If you're talking about the audio part of a video file it's still a very small percentage of the total size.

If the source is stereo and you reencode it to mono it's going to come out worse. That's the simple fact.

[elmuz]

Well... I mean...
1) I have an amount X of bits to be used (64kbps). If I encode a stereo track I have to use these bits to rapresent the double of uncompressed sound... I *suppose* it gonna be worse...

2) No, I did two different tests. Starting from "MONO.wav" I encoded to "mono.aac". Then I made a fake stereo wave, doing a twin channel from MONO.wav and I encoded it as "stereo.aac"

The image show the first "mono.aac" and one channel (the left I think) from "stereo.aac"..

[poisondeathray]

If you are using waveforms, you should compare to the original file (ie. which is more like the original? )

Also, listen to the files => which is more like the original ?

I think there is more noise in the stereo file, the original waveform is not reproduced as well

Also, if your goal is low bitrate... you shouldn't use CBR encoding

[El Heggunte]

Just to make things more complicated , you should also try other AAC encoders, like enc_aacplus, fhgaacenc and qaac.

Besides, given that storage space is cheap nowadays, I don't see the point of using very-low bitrates for audio compression.

[poisondeathray]

Most people think between nero and qaac are probably the better aac encoders, but according to some subjective tests qaac has slight edge at 64kbps
http://forum.doom9.org/archive/index.php/t-160185.html
http://listening-tests.hydrogenaudio.org/igorc/results.html

Besides, given that storage space is cheap nowadays, I don't see the point of using very-low bitrates for audio compression.

I think he's doing it for streaming / flash - bandwidth is always an issue $

[elmuz]

If you are using waveforms, you should compare to the original file (ie. which is more like the original? )

Also, listen to the files => which is more like the original ?

Pretty sure the stereo is more similar to the original graphically speaking, apart from the high frequencies cut. I remember the original was full of spectrum till 22kHz.

Also, if your goal is low bitrate... you shouldn't use CBR encoding

You're right! Everything started at work talking with colleagues... We have professional ISDN codec 128kbps (two ways: 64kbps one way + 64kbps way back). It encodes in HE-AAC (stereo) or AAC-LD (mono)... We use it mainly for voices... we can't choose VBR and most of all we can't choose encoder.

I just wanted to prove that -HE-AAC (SBR, no PS) mono (not even sure we can set it that way o the ISDN codec) would be better than HE-AAC (stereo) as we usually do. Consider it encodes a dual-mono signal coming from microphone...

So I did that sort of test on my own... but I found results quite surpising...

[El Heggunte]

I think he's doing it for streaming / flash - bandwidth is always an issue $

Thanks for the reminder, sadly I keep forgetting those "irrelevant" details.

[poisondeathray]

Pretty sure the stereo is more similar to the original graphically speaking, apart from the high frequencies cut. I remember the original was full of spectrum till 22kHz.

I had a closer look you're right . Definitely in the middle section

But doesn't the stereo output sound a bit more noisy overall? Or is it just me ??

Maybe something wrong with nero's encoder or the settings used?

[jagabo]

Keep in mind that many codecs internally split stereo into a mono track (R+L) plus a difference (R-L) track (ie, "joint stereo"). In that case, a stereo track with identical data on the left and right channels is the same as a mono track.

http://en.wikipedia.org/wiki/Joint_%28audio_engineering%29

[Mephesto]

This thread is so lame. If you use the same bitrate for a stereo song as a mono, what do you expect but the stereo one to be worse quality, Einstein? Holy shit. What a discovery of the century here.

Besides, given that storage space is cheap nowadays, I don't see the point of using very-low bitrates for audio compression.

Average global Internet speed is still slow as ****, genius. I don't know about you but I hate waiting hours to either send or receive from a friend.

Most people think between nero and qaac are probably the better aac encoders, but according to some subjective tests qaac has slight edge at 64kbps

PDR, for once you are wrong. WMA is actually the best codec at 64kbps, with 70% of listeners in a subjective test preferring it over HE-AAC. It's weird but true.

What's even weirder is that Nero AAC at CBR is better quality at 64kbps than VBR at the same bitrate. I have no idea why.

[poisondeathray]

Most people think between nero and qaac are probably the better aac encoders, but according to some subjective tests qaac has slight edge at 64kbps

PDR, for once you are wrong. WMA is actually the best codec at 64kbps, with 70% of listeners in a subjective test preferring it over HE-AAC. It's weird but true.

Actually you're wrong , or just didn't read very well. WMA isn't an AAC encoder

What's even weirder is that Nero AAC at CBR is better quality at 64kbps than VBR at the same bitrate. I have no idea why.

You sure about that one? Or is this opinion ?

[Mephesto]

Actually you're wrong , or just didn't read very well. WMA isn't an AAC encoder

I did read you wrong, I missed the "aac" part in your post.

You sure about that one? Or is this opinion ?

Positive. I've done listening tests a few years ago when the results of a previous listening test confused me. Here it is:

ABC/HR Version 1.0, 6 May 2004
Testname: DRE AAC XBR

1L = C:\Documents and Settings\Admin\Dre64abr.wav
2R = C:\Documents and Settings\Admin\Dre64cbr.wav
3L = C:\Documents and Settings\Admin\Dre64vbr.wav
4L = C:\Documents and Settings\Admin\Dre80cbr.wav

---------------------------------------
General Comments:

---------------------------------------
1L File: C:\Documents and Settings\Admin\Dre64abr.wav
1L Rating: 3.7
1L Comment: A bit dull, cymbals slightly distorted.
---------------------------------------
2R File: C:\Documents and Settings\Admin\Dre64cbr.wav
2R Rating: 4.6
2R Comment: Cymbals slightly distorted and feels slightly dull I think.
---------------------------------------
3L File: C:\Documents and Settings\Admin\Dre64vbr.wav
3L Rating: 3.9
3L Comment: Better than 1 I think, less dull and wider stereo.
---------------------------------------
4L File: C:\Documents and Settings\Admin\Dre80cbr.wav
4L Rating: 4.0
4L Comment: OK, cant really tell this apart from last one, but I believe it's slightly better.
---------------------------------------
ABX Results:
Original vs C:\Documents and Settings\Admin\Dre64abr.wav
18 out of 19, pval < 0.001
Original vs C:\Documents and Settings\Admin\Dre64cbr.wav
17 out of 20, pval = 0.001
Original vs C:\Documents and Settings\Admin\Dre64vbr.wav
16 out of 20, pval = 0.006
Original vs C:\Documents and Settings\Admin\Dre80cbr.wav
16 out of 20, pval = 0.006

And my findings are confirmed here: http://soundexpert.org/encoders-64-kbps

Actually you're wrong , or just didn't read very well. WMA isn't an AAC encoder

I did read you wrong, I missed the "aac" part in your post.

You sure about that one? Or is this opinion ?

Positive. I've done listening tests a few years ago when the results of a previous listening test confused me. Here it is:

ABC/HR Version 1.0, 6 May 2004
Testname: DRE AAC XBR

1L = C:\Documents and Settings\Admin\Dre64abr.wav
2R = C:\Documents and Settings\Admin\Dre64cbr.wav
3L = C:\Documents and Settings\Admin\Dre64vbr.wav
4L = C:\Documents and Settings\Admin\Dre80cbr.wav

---------------------------------------
General Comments:

---------------------------------------
1L File: C:\Documents and Settings\Admin\Dre64abr.wav
1L Rating: 3.7
1L Comment: A bit dull, cymbals slightly distorted.
---------------------------------------
2R File: C:\Documents and Settings\Admin\Dre64cbr.wav
2R Rating: 4.6
2R Comment: Cymbals slightly distorted and feels slightly dull I think.
---------------------------------------
3L File: C:\Documents and Settings\Admin\Dre64vbr.wav
3L Rating: 3.9
3L Comment: Better than 1 I think, less dull and wider stereo.
---------------------------------------
4L File: C:\Documents and Settings\Admin\Dre80cbr.wav
4L Rating: 4.0
4L Comment: OK, cant really tell this apart from last one, but I believe it's slightly better.
---------------------------------------
ABX Results:
Original vs C:\Documents and Settings\Admin\Dre64abr.wav
18 out of 19, pval < 0.001
Original vs C:\Documents and Settings\Admin\Dre64cbr.wav
17 out of 20, pval = 0.001
Original vs C:\Documents and Settings\Admin\Dre64vbr.wav
16 out of 20, pval = 0.006
Original vs C:\Documents and Settings\Admin\Dre80cbr.wav
16 out of 20, pval = 0.006

And my findings are confirmed here: http://soundexpert.org/encoders-64-kbps

EDIT: LAME MP3 is also way better quality at ABR than VBR at bitrates lower than 96. I've come across all sorts of weird logic-defying shit like this in my years of working with video and audio.

[hello_hello]

Quite a while back I was involved in a discussion in another forum regarding the Nero encoder. I can't remember the exact details, but we discovered that when using a particular quality setting it would generally produce a slightly larger file size than you'd otherwise get when increasing the quality a little. In other words, increasing the quality reduced the file size rather than increased it, but only when encoding using a few specific quality values.

It turned out this was a result of using quality settings around the "cut off point" where the encoder switched from using one algorithm to another. Or so I was told. I don't know if this meant the quality increase isn't always linear as you'd expect when increasing the encoder quality, as the particular settings were way lower than the Q.50 I normally use for encoding so I didn't investigate any further.

Anyway, the point of my story..... maybe the encoder uses different algorithms etc for mono files than it does for stereo at certain bitrates etc. Similar to the way LAME uses different algorithms even when the bitrate is the same if you specify a quality other than the default. That'd possibly explain the unexpected results when comparing mono and stereo encodes at a low constant bitrate. Maybe I'm way off track, but it's just some thoughts.....

[elmuz]

This thread is so lame. If you use the same bitrate for a stereo song as a mono, what do you expect but the stereo one to be worse quality, Einstein? Holy shit. What a discovery of the century here.

...so genius, why graphs seem to disagree with you?

[Mephesto]

Wow, did I just say the same shit twice in post #13? No idea what I was smoking that night but it was 4:30 in the morning...

Anyway, hello_hello partially answered your question of why your STEREO track appeared better quality. Your mono track was encoded with the regular LC-AAC algorithm while the stereo was encoded with HE-AAC which uses SBR to replicate the upper frequencies.

Nero AAC encoder automatically chooses which feature to utilize depending on the circumstances. For a stereo 44.1 khz track, selecting a bitrate below 96 generally auto-enables SBR so the quality wont suck too bad. Going below 48 will auto-enable Parametric Stereo (PS) which replicates stereo in the same fashion as SBR replicates frequency.

Because 64 kbps doesn't sound too bad with mono, Nero decided SBR wasn't necessary. Those gaps in the upper shelf you noticed are not really audible when you ABX. 64 kbps mono is pretty much equivalent to 112 kbps stereo which is transparent for most music.

If you want, you can disable both SBR and PS by adding -lc into your script and -he to only disable PS. 64 kbps stereo without SBR will look a lot worse on your spectrograph chart than the mono track.

[elmuz]

Ok, now sounds better... I forced SBR for both mono and stereo...

Now graphs seem more legit ...anyway there's still a little loss of information on high frequencies, and lots of artifatcs..

[El Heggunte]

Hmmm, now it seems this thread is not that "lame", after all.

[elmuz]

Hmmm, now it seems this thread is not that "lame", after all.

Anyway I don't like what I got as results.

[Mephesto]

Hmmm, now it seems this thread is not that "lame", after all.

Sleep-deprivation and a poorly laid-out thread works wonders.

elmuz, your screenshots were better annotated this time and less confusing.

You should ABX the results and stop looking at a spectrograph, though. The loss in those upper frequencies are above 15 kHz which majority of people older than 14 cant hear, and those blips you see at the top are tiny clipping errors (which spectrographs have a hard time representing) from your already-clipped Rihanna track that you probably got off Youtube.

If you're concerned about the quality of audio, rate it with your ears, not eyes.

[elmuz]

You should ABX the results and stop looking at a spectrograph, though. The loss in those upper frequencies are above 15 kHz which majority of people older than 14 cant hear, and those blips you see at the top are tiny clipping errors (which spectrographs have a hard time representing) from your already-clipped Rihanna track that you probably got off Youtube.

If you're concerned about the quality of audio, rate it with your ears, not eyes.

Well.. ok! I'll try just using ears I just wanted proving that encoding mono is better than stereo in our low bitrate conditions (and mono source, microphone)
Anyway it was a "Paranoia" ripped track directly from the original Rihanna CD. If it seems clipped it's Audacity's rapresentation fault..

[El Heggunte]

... the original Rihanna CD....
If it seems clipped it's Audacity's rapresentation fault..

Rihanna? ERROR: No such file or directory

All that I know about her is, her first album was released in 2005, and she does not record classical music --- so yes, her CDs are expected to contain some tons of clipping

[Intel Core i7]

shivaree-goodnight moon

[Intel Core i7]

https://forum.videohelp.com/threads/346597-AAC-stereo-vs-AAC-mono?p=2172368#post2172368

is better how? or is it mono sounds worse in one ear?

mono channel is
m=f(tau) = a(tau) cosg(tau)

so you built
s=f(tau) = a(tau) cosg(pi/2-tau)
,a amplitude in file such as form
tau, no of audio frame

so you have a form that has a distribution such as the reds in picture

any teacher in maths can add pi/2-tau+_deltaphase to pin harmonic frequencies so you get blue if that circle targets such harmonic form.

a form may
a(tau) =15.69231pix same with 32769pix precision in common waves w sign
cosg(tau)= cos(ax+bx^2+cx^3+tau), distribution of clipp (3decibels)
cosg(tau_0) = sin(m tau_0 +n tau_0^2+ timelength_in_mono_track/sampling_rate),

so you target tau=tau(a,b,c) from my eq. cosg(tau_0)==cos(tau) and the maths i find
tau = arcsing(m tau_0 + n tau_0^2 + timt/sr )\fraq{(ax+bx^2+cx^3)}
as t =tau
cosg(t)= sin( ax+6 bx^2+cx^3+t)
and homogenise it down to
cosg(t)= sin( ax+6 bx^2+cx^3+t)

Now lets find the harmonic freqvs. First circle should be a pole that has a minimum amplitude and maximum (red)distorsion. Measure the sample and find frequency 1/tau_0 star x. Time is x so 1/tau_0 is length samples_in_track.

timt=1772frames
lows_center=10.61538pix, în image
~highs_rest=15.69231pix,neighbor limits_left and _right sides
I want to hear it so tau_0=35frames is audible and follows pole zero
Interval in zero is 8frames long, that’s 20.92308pix.

Lower audible freq 1/tau = 16hz ~ 16frames, true? Statistical in picture 35frames is:
Frames hz_equiv pix_units
1772 110.75 2363.077
35 2.1875 same (46.6)
8 (10.65143)
so you may hear brown noise at playback. So freq I hear in 35frames eq 46.6pix

At left side în circle find the derivate value d(_gtau)/ds for find core freq (one you pick as brown noise)
d/ds (_ltau) = d/ds (cosg)(ltau) = do math = gtau_1eft

that`s horiz_length_ for max amplitude cosg(gtau_left) and should read 15.69231pix. Lets check frequency at leftside of circle.

Cosg(gtau_left) = do math > 46.6pix
Gtau_left=(35-8)*1772/1920=27.91875pix

Lets do it!
-find deriv_value
d/ds Cosg(gtau_left)= cos( ax+6 bx^2+cx^3+t) (a+2 bx+6cx^2+ ltprime)
ltprime=[1/sqrt(1- (m tau_0 + n tau_0^2 + timt/sr)^2) (ax+bx^2+cx^3) - (a+2bx+3cx^2) arcsin(m tau_0 + n tau_0^2 + timt/sr) ]\fraq{(ax+bx^2+cx^3)}^2

d/ds cosg(gtau_lef)=cos(u+[u\fraq{\sqrt{sing(uprime)}}+a+u` arcsin(uprime=1)\fraq{uu}]] = (15.69231 - 10.61538)\fraq{2.1875} = 2.321243

made aproximations:
u = ax+bx^2+cx^3
u`=a+2bx+6cx^2
uprime= m tau_0 + n tau_0^2 + 2.1875+2pi\fraq{2}

2.321243=cos(u+[u\fraq{\sqrt{sing(uprime)}}+a+u` pi\fraq{uu}]])
2.321243=cos(ax+bx^2+cx^3+[ . . .]+ (a+2bx+3cx^2)\fraq{ax+bx^2+cx^3-0.1} pi\fraq{uu})

After replacing u,u`,uprime find gtau_lef= &gtau_right=
Assuming (m_0,n_1)fit armonic to overlap în origins.
X [pix] you may find m=m(x), let n=0

So m_1=m(0.1pix)=0 and m_last=m(1771.9)=whatever < 46.6 tops

if calculus is right someone find m(24.91875)= against

d/ds ((24.91875 tau_0 +0 tau_0^2+ 2.1875)\fraq{(ax+bx^2+cx^3)+pi}) =
= 2.321243

24.91875 d/ds ((tau_0+2.1875/24.91875)\fraq{(2.1875 a+4.785 b+10.46 c)+pi}) =
= 2.321243

ds=110.75/2363.077
e(a,b,0,pi) = 24.9\fraq{2.3} 2363.077\fraq{110.75}
2.1875a+4.785b+pi=230.9966

Ideally reactangle is half filled up for mono signals so a\cdot{b}=area\sqrt{2}
Please compute colours height în pix în picture and find proficiency of AAC codec for that particular digital sound.
b= (230.9966-pi-2.1875a)\fraq{4.785}=4.61873-0.457158a

remember cosg(ax+bx^2+cx^3)?
Cosg(ab0)=cos(a pix+4.61873pix^2-0.457158a x^2}]+c)=cos(omega_tau) that’s it

You have tau_int_left=2/1920 1772/1920
Tau_int_right=(1920-2)/1920 1772/1920 for the horizontal intervals
The tau variab you find for the circle represents the samping interval with lack of rendering,în (pix,pix)coordinates,originating at (15.69231,46.6), please allow homework because 46.6originated from (35)not (35-2) that’s for future lesson, !no 15.69231!

Amplitude in null area lacks sample_rates\cdot{sample_rate} number of frames (or pix) lasting (gtau_left,to,gtau_right)interval that’s 10.65143pix [1772/1920]units that`s a 170.4229hz low pass filtering


========= =========
Starting from the the right_side of the image mcad should find a similar result increasing maybe error tolerant epsilon. (simply try to replace 1772 with 35 and 35 and 1772 and tell me a result)

Conclusion:
1.take a 1920x1080image as a sound.
2.consider each discrepancy as audible just as în picture. Frame each_circle.

Note1 You may want to hear so any one must render greater than 16hz. Say its true and you hear it so entire image may drop frequency down to 35*dpi/1920 hz. Samples în image count 16hz/dpi. For me picture shows 5.647 *1772pixs*dpi and image size is 177.1981mils w some 1.9817250error
3.find a freqv to have a maximum value at centre discrepancy and find a tau_values to centre of discrepancy_1, _2,. . .
Gcos (tau)=sin (omega_tau+c)
4.replace omega with
Gcos()=cos(ax+bx^2+cx^3)
Where from upperlines u find omega=arcsin(ax+bx^2+cx^3)/(m tau+n tau+c)
5discrepancy seemed spotted so let n=0 to simplify. What maths does forums know?
omega=asin(ax+bx^2+cx^3)/(m tau)
,u may encounter omega=arcsin{ ax+bx^2+cx^3}\fraq{m\cdot{tau}}, or a\cdot{x}
6.got omega? Name it omega==2pi f, where f measures în pix]-units. I found
f=46.6 + 49.5803
expected 46.6+110.75/16
7.discontinued frequency în circle`s (46.6f+49.58f)/2 (1/dpi=1920/170)=17.031875hz laying on 16.0hz. Envelope mark covers 1.031875hzwide. alternate method requires speed of sound in picture
8.find me a particular transform filter for that 1.0.31875hz în spectral view,to render audio that`s stored în _stereo_ wav. I called it brown noise because it has a lower that 110.1985hz freq (that’s 2363.077pix a sec) and starts from 16hz (46.6pix).
Conclusion#2:
-AAC.AX filter, better say AAC nero coder trims original freqvs in tester_mono.WAV represented by the gcos(tau)- distribution în the image,by clipping very stif pitches of less than log(10.61538pix/15.69231pix) in 0.1bell units -0.16975dB
-is that rude for a hi-fi codec? Remember: codec codings have a denaturation,either harmonic distorsion,în this case close to latter 19.6911bits,meaning that image represents a 10011bit precision drop in codec-decoding precision within tester_mono.AAC (assume 00000precision în tester_mono.wav). Its may due to AAC decoding (that’s errors in color values display) aswell as nero compressing which is not likely.
-do not confuse precision în rendering with:
*precision of AAC algorithm (meaning supervised losses of quality);
*precision of rendering (brown noise users hear is because of speakers,amplifier,receiver,etc and has nothing to do with dvd or file;afterall have u seen speakers to wear 24bit tag?;
*precision of image of elmoz and finally the rulers I used.

Precision=(lossly aac+precision render) picture precision + my accuracy

========= ========= ========= =========
Recomandation.
-Pick a speaker with a maximum peak fidelity in AAC codec maximum drop interval
-use a delay echo between channels so let it use undoc specs în AAC to widen this interval so version2-codec could improve
-use a dedicated DSP to smooth out AAC clippings. If you can show MP3 clippings probably it would wont suit because its clips cut down to infinite (16bit actually). Pure sucked freqvs i.e. are:
16hz eq 46.6pix
110hz eq 1920p
Harm.f are
46.6Pix times order or
110PIX times order
For the 16hz (46.6pix) the fidelity ears cover as many as
46.6times 1/2^csi octaves
That csi depends on energy the human ear hears (depicted as Area of precision drawing in picture or length of Tester_Samples.WAVES). Energy distribution în picture is 1920x1080 times dpi times (1772/1920area) [pix dpi^(-2) / hz]; My dpi^2=11.294117^2pix/mil

Further readctaves and human earing, and human hearing, acoustic analogy (various authors); Automated programs and algorithms for Jet Engines purposes-Paul Peteerson,MSDN library,COM interfaces,mpeg-4codeccomparison.ru,any algorythm encyclopedias.

========= ========= ========= =========