Why is MeGUI encoding 5.1 AAC at 96KHz Sampling Rate???

[Blue_MiSfit]

Hey folks,

So after much difficulty getting my computer stable again, I got MeGUI installed last night and all updated, with neroaacenc_SSE2.exe handling the AAC encoding. I setup an automatic 1/4 DVD-R rip of Jarhead, with a tweaked HQ-Slower profile ( custom matrix ), and the default audio settings, albeit with the Q factor adjusted to .45.

When I came in this afternoon to check the result, the AAC decoder pin indicated that the input was 96KHz...

The audio is using more space than the original AC3, which is a standard 5.1 48 KHz 448kbps track.

Am I missing something? I noticed that in the new audio config dialog, there is an option about using 32 bit / float to increase accuracy. Is this possibly upsampling to 96KHz somwhere?

Love the new MeGUI design however. Everything works so freaking well so far! No more dredging the forums to get all the bits and pieces together for a working encode.

Thanks devs.

~MiSfit

[Blue_MiSfit]

I redid the encode and everything worked fine. Very strange.

[Zaeleus]

I am also having this happen and am wondering about it. Using NeroDigital AAC, the audio comes out as 96000 Hz. I tried with FAAC, and it comes out at the proper 48000 Hz it was originally set at.

Edit: I just checked the log, and how odd. It even checks it as 48000 Hz at first.
Log for job job5-1

Channels=2, BitsPerSample=16, SampleRate=48000Hz
C:\Program Files\megui\tools\neroaacenc\neroAacEnc_SSE2.exe -ignorelength -q 0.5 -if - -of "C:\DVD_VIDEO\VIDEO_TS\VTS_01_CHAPTER_01_1 T01 48K 16bit 2ch.mp4

[Blue_MiSfit]

I think we may have a sporadic bug in the free nero digital encoder...

[shon3i]

Probably is nero see2 bug, i don't see that bug in sse version

[SeeMoreDigital]

I noticed sometime ago, Nero's free AAC encoder likes to generate AAC-HE encodes at the same sample rate as the source, instead of half it's sample rate (which I believe is good practice).

I wonder, does MeGUI double the sample-rate of AAC-HE streams during encoding so they match the source too? If so, it could be doubling, what has already been doubled.... If you get my drift?


Cheers

[Kurtnoise]

I think we may have a sporadic bug in the free nero digital encoder...
Probably is nero see2 bug, i don't see that bug in sse version

Come on guys...before to complain about something, try to make some extra tests before to claim or to find a bug. Personally, I tried with a AC3_6ch stream @448 kbps with foobar and sse2 version and you know what ? It works fine...

So, there are 3 points regarding your issue :
You don't know how to set the command. In this case :readguid:
Your decoder has a problem.
There is a bug into MeGUI.

So, try to find the right answer...

I noticed sometime ago, Nero's free AAC encoder likes to generate AAC-HE encodes at the same sample rate as the source, instead of half it's sample rate (which I believe is good practice).
your believes are wrong...:search:

[shon3i]

Come on guys...Why?, i don't have SSE2 machine, and SSE encoder with MeGUI work's like charm.

I noticed sometime ago, Nero's free AAC encoder likes to generate AAC-HE encodes at the same sample rate as the source, instead of half it's sample rate (which I believe is good practice).
No, that's be Downsampled SBR wich means encoder encode audio at 88.2 khz and downsample it 44.1khz (Nero don't use this tehnique), Nero always encode to 22khz and when playing that is 44.1 like CT, but CT HE-AAC High is Downsampled SBR

[SeeMoreDigital]

No, that's be Downsampled SBR wich means encoder encode audio at 88.2 khz and downsample it 44.1khz, Nero always encode to 22khz and when playing that is 44.1 like CT, but CT HE-AAC High is Downsampled SBRIf the source was AC3 at 48KHz, then twice 48KHz would equal 96KHz ;)


Hi Kurt,

When generating MP3 Pro encodes from audio CD (41.1KHz) sources, using say MusicMatch, the sample rate is listed as being half that of the source ie: 22.050KHz. Similarily, when generating AAC-HE encodes from audio CD (41.1KHz) sources, the sample rate can also be listed as being 22.050KHz, especially if the application that's reading the encode is unable to detect the SBR indicator.

For instance, if I use BeLight to generate an 2Ch AAC-HE stream (from an 41.1KHz source), with Nero's CLI codec, MediaInfo reports this: -General #0
Complete name : T:\TEST Media Files\Nero's CLI AAC-HE Encoder Test.m4a
File size : 3.43 MiB
Format : 3GPP (MPEG-4)
Overal BitRate : 130 Kbps
PlayTime : 3mn 41s
Writing library : Nero AAC codec / May 26 2006

Video #0

Audio #0
Codec : AAC LC
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 22 KHz
PlayTime : 3mn 43sNote: The bit-rate is listed and the sample rate 22(.05)KHz.


If I use BeLight to generate an 2Ch AAC-HE stream with CT's codec, MediaInfo reports this: -General #0
Complete name : T:\TEST Media Files\CT's AAC-HE Encoder Test.aac
File size : 3.41 MiB
Format : Advanced Audio Codec

Audio #0
Codec : AAC
Family : MPEG-4 AAC
Codec profile : LC-SBR
Channel(s) : 2 channels
Sampling rate : 44 KHzNote: The bit-rate is not listed but the sample rate is at 44(.1)1KHz


However, if I mux this stream into the MP4 container using YAMB (even with HE-AAC signalling), MediaInfo reports this: -General #0
Complete name : T:\TEST Media Files\Nero's AAC-HE CLI Encoder Test.mp4
File size : 3.40 MiB
Format : MPEG-4 version 2
Overal BitRate : 128 Kbps
PlayTime : 3mn 43s

Audio #0
Codec : AAC LC
Bit rate : 127 Kbps
PlayTime : 3mn 43sNote: The bit-rate is now listed but the sample rate isn't.


...Different encoders both set to generate AAC-HE streams but providing different stream information ;)

[shon3i]

If the source was AC3 at 48KHz, then twice 48KHz would equal 96KHzYes, but that can't be because Nero not use Downsampled SBR, only normal SBR (which means if you encode 48khz you get 24khz file, but on play every normal decoder (FAAD,ffdshow,..) will automaticly upsample to 48khz), aslo CT HE-AAC High only support stereo files.

When generating MP3 Pro encodes from audio CD (41.1KHz) sources, using say MusicMatch, the sample rate is listed as being half that of the source ie: 22.050KHz. Similarily, when generating AAC-HE encodes from audio CD (41.1KHz) sources, the sample rate can also be listed as being 22.050KHz, especially if the application that's reading the encode is unable to detect the SBR indicator.

For instance, if I use BeLight to generate an 2Ch AAC-HE stream (from an 41.1KHz source), with Nero's CLI codec, MediaInfo reports this: -Trust me use the foobar to generate correct info's, aslo i have same confusing about mp3PRO because any decoder not reconstruct signal, and i don't know what is the catch

[SeeMoreDigital]

Yes, but that can't be because Nero not use Downsampled SBR, only normal SBR (which means if you encode 48khz you get 24khz file, but on play every normal decoder (FAAD,ffdshow,..) will automaticly upsample to 48khz), aslo CT HE-AAC High only support stereo files.
Who mentioned anything about "downsampling"?

I'm only reporting the value's some info reporting tools list!

Personally I prefer how MP4Box lists the sample rate information as it does not lead anything open to interpretation!

CT's Encoder Test.mp4 or .m4a: -
Track # 1 Info - TrackID 101 - TimeScale 22050 - Duration 00:03:43.236
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 4807 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x67
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 22050 - SBR SampleRate 44100
Synchronized on stream 1

Nero's CLI Encoder Test.m4a: -
Track # 1 Info - TrackID 1 - TimeScale 44100 - Duration 00:03:43.172
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 4806 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 22050 - SBR SampleRate 44100
Self-synchronized

..... But note the "TimeScale" differences!


Cheers

[shon3i]

Who mentioned anything about "downsampling"?
Nobody, that is name for that encoding metod (aka oversampled, and High encoder (CTAAC work title)), So because nero don't use over/downsample SBR, when encodig 48khz must be 24khz and when playing must be 48khz, i encode many movies with new nero encoder (in megui) i i newer get 96khz.

So one reason why get 96 is very bad decoder or like i say only foobar have real correct information for aac by now.

[SeeMoreDigital]

So because nero don't use over/downsample SBR, when encodig 48khz must be 24khz and when playing must be 48khz...I don't quite understand what you are trying to say.... But as you can see from MP4Box's information Nero's AAC-HE encodes clearly have a SampleRate of 22050.

So one reason why get 96 is very bad decoder or like i say only foobar have real correct information for aac by now.Indeed Foobar's information (see below) is not bad....

CT's Encoder Test.aac: -
bitrate = 128
samplerate = 44100
channels = 2
aac_profile = AAC HE
codec = HE AAC
aac_header_type = ADTS
----------
9844736 samples @ 44100Hz
File size: 3 571 788 bytes

CT's Encoder Test.mp4: -
bitrate = 127
samplerate = 44100
channels = 2
aac_profile = HE AAC
codec = AAC
----------
9844736 samples @ 44100Hz
File size: 3 560 915 bytes

Nero's CLI Encoder Test.m4a: -
bitrate = 128
samplerate = 44100
channels = 2
aac_profile = HE AAC
codec = AAC
tool = Nero AAC codec / May 26 2006
----------
9841912 samples @ 44100Hz
File size: 3 599 751 bytes

But l prefer the way MP4Box does it ;)

[SeeMoreDigital]

Hmmm...

Using BeLight and with CT's encoder set to "HE AAC High" and look what I got: -

Media Info reports: -
General #0
Complete name : T:\TEST Media Files\CT AAC-HE High.aac
File size : 3.40 MiB
Format : Advanced Audio Codec

Audio #0
Codec : AAC
Family : MPEG-4 AAC
Codec profile : LC
Channel(s) : 2 channels
Sampling rate : 44 KHz

But Foobar Info reports: -
bitrate = 128
channels = 2
samplerate = 88200
aac_profile = AAC HE
aac_header_type = ADTS
codec = HE AAC
----------
19681280 samples @ 88200Hz
File size: 3 570 301 bytes

And when the same stream is muxed into the MP4 container without "HE-AAC signalling", MP4Box reports this: -Track # 1 Info - TrackID 101 - TimeScale 44100 - Duration 00:03:43.143
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 9610 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 44100
Synchronized on stream 1

But if I add "HE-AAC signalling", MP4Box reports this: -Track # 1 Info - TrackID 101 - TimeScale 44100 - Duration 00:03:43.143
Media Info: Language "Undetermined" - Type "soun" - Sub Type "mp4a" - 9610 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 44100 - SBR SampleRate 88200
Synchronized on stream 1

I suspect when Nero's CLI encoder to "HE v2" it may be generating weird sample-rates too... Looks like we may be getting somewhere... :scared:

[shon3i]

Easy, first.

SBR tehnique is maded to encode all frequencyes above 11khz, and below 11khz encoder use LC-AAC, so because LC-AAC have 11khz*both channels=22khz, and SBR is other else wich is other 22khz which is recontruct by decoder, btw, SBR means Spectral Band Replication, which means that decoder with some magic reconstruct how much possible cutted high frequencyes.

So then if you encode that file and you have 22khz that is everything fine because mp4box show's info of the file, not info of decoder, and foobar show info of decoder. for example info from CoreAAC

http://img169.imageshack.us/img169/1247/coreaac8sf.jpg

You see original file have samplerate of 24khz but decoder it reconstruct to 48khz

I don't quite understand what you are trying to say.... But as you can see from MP4Box's information Nero's AAC-HE encodes clearly have a SampleRate of 22050.
Aslo mp4 container have some different info than aac and mp4 always show real samplerate than aac (aac shows playing samplerate, but that is same thing), but for example winamp's info box aslo have orig samplerate, play samplerate etc.

Using BeLight and with CT's encoder set to "HE AAC High" and look what I got: -

First Downsampled SBR, encode's file to 88.2 because to can force SBR encoder to encode freqencyes above 14khz - 22khz instead 11khz, Encoder automaticly downsample back that file to 44khz, and when playing recontruct back to 88khz, so if you see 88khz for samplerate that is because in mp4box not supported DSBR signalling like in winamp encoder, and that foobar which you use have bug (probably is 0.83) because show's 88khz for aac

[SeeMoreDigital]

Well thanks for the lesson.... but I'm very familar with what constitutes an AAC-LC and AAC-HE encode, including what SBR is!

Are you able to offer a reason as to why Blue_MiSfit's encode shows a sample-rate of 96KHz?

Maybe it would be useful if he could confirm which decoders "decoder pin" provided him with the erroneous "sample-rate information. And was he playing the elementary ADTS .AAC stream or was it muxed into the MP4/M4A container?

EDIT: .... and mp4 always show real samplerate than aac (aac shows playing samplerate, but that is same thing).. I think you'll find, it's very easy to trick the MP4 container into supplying the wrong information!


Cheers

[shon3i]

Are you able to offer a reason as to why Blue_MiSfit's encode shows a sample-rate of 96KHz?
I have no idea, but he can help if split some part from encoding and upload as sample, and options what use in megui (screenshoot and log).

[SeeMoreDigital]

I have no idea, but he can help if split some part from encoding and upload as sample, and options what use in megui (screenshoot and log).Agreed!

[Blue_MiSfit]

I was using the internal MPC decoder, whatever library that is based on. The AAC was inside an MP4 container generated by MeGUI, so I assume that means mp4box.

The settings in MeGUI were the defaults, with the Q factor adjusted to .45 from a default of .5

Again, when I started over using the exact same source and MeGUI procedure, I got the correct result. Of course, I over-wrote the "bad" files, and don't have the logs anymore. I have not seen the problem since and have done several encodes.

If I see it again, I will definately take some screenshots and keep all the input and output files so that a proper bug report can be done. I know my report wasn't very complete, it just seemed like a one time thing to me. I have been having a lot of computer problems which have just recently been resolved. I chalk the error up to that for now... Still, the ongoing debate seems to be going in a logical direction.

Finally,
@ kurtnoise13

1) I do know how to use the AAC encoder inside MeGUI. It is extremely simple.
2) there could be a decoder problem.
3) I think its more likely there is a problem with MeGUI, given its active development state.

I didnt mean to complain. I was merely asking if anyone had encountered simmilar problems. The problem has gone away, and I'm not claiming that there is a bug in anyone's software. Just trying to get a little more info :)

Anyway, thanks for the replies. It seems like other people are having similar issues. I hope it gets resolved.

~MiSfit

[Zaeleus]

I tried a couple of tests, and this is what I found. The information is produced by ffdshow 2005-04-30 CCCP build.

File: VTS_01_CHAPTER_01_1 (cut).vob (http://www7.spread-it.com/dl.php?id=1e42def227a4e9a66aec3f31c4f4ffb2c78dba86)
Opening the original vob and viewing the information on the audio, it clearly is 48000 Hz.

http://img120.imageshack.us/img120/9830/2006062915ap.png (http://imageshack.us)

File: VTS_01_CHAPTER_01_1 (cut) T01 48K 16bit 2ch.mp4 (http://www7.spread-it.com/dl.php?id=313449c6095d57d5169971c20ea2fec96a927c28)
Saving the wav and encoding using the Nero Digital Audio encoder (http://www.nero.com/nerodigital/eng/Nero_Digital_Audio.html) 1.0.0.2 (neroAacEnc_SSE2.exe), I still get the original 48000 Hz in the aac file.
neroAacEnc_SSE2.exe -ignorelength -q 0.7
-if "VTS_01_CHAPTER_01_1 (cut) T01 48K 16bit 2ch.wav"
-of "VTS_01_CHAPTER_01_1 (cut) T01 48K 16bit 2ch.mp4"

http://img182.imageshack.us/img182/8564/2006062921tf.png (http://imageshack.us)

File: VTS_01_CHAPTER_01_1 (cut)-muxed.mp4 (http://www7.spread-it.com/dl.php?id=f6f0d7e0cb654b0ace0ecbd42477182328c932aa)
Muxing it with in the mp4 container with a video stream, it still is 48000 Hz.

http://img120.imageshack.us/img120/6595/2006062937ip.png (http://imageshack.us)

File: VTS_01_CHAPTER_01_1 (cut)-muxed.mkv (http://www7.spread-it.com/dl.php?id=cd76918e781f6f813dbf1d5174ccf2133ac5d73a)
Next was muxing to mkv. That's when the sample rate jumped to 96000 Hz.

http://img325.imageshack.us/img325/677/2006062943fx.png (http://imageshack.us)

So there seems to be something up when muxing to Matroska. Hopefully any of what I posted will be useful to someone to try to figure out why that happens.

[Blue_MiSfit]

Bingo. I forgot to mention my final encode was in the MKV container. This is consistent with the previous post.

[foxyshadis]

Someone checked the "sbr" box when they weren't supposed to... not necessarily you, sounds like it was MeGUI's fault.

If it plays without sounding like chipmunk land it probably won't hurt it, just use extra cpu trying to oversample (just to get sampled back to 48 on output).

[shon3i]

Probably MeGUI signal alredy signaled mp4 file, and in that case samplerate is doubled. So where mux mp4 file never use -sbr switch because mp4 is alredy signaled.

[foxyshadis]

No, if it's HE you must use -sbr, if it's not you must not. Since the current nero encoder makes this decision automatically (and according to the devs should never be forced), MeGUI should check after the encode whether or not HE was used via mediainfo (the latest versions will tell you if it's SBR or not) and call mkvmerge based on that. MP4 actually doesn't signal HE, and while the bitstream does mkvmerge doesn't attempt to parse the raw bitstream.

[shon3i]

No, if it's HE you must use -sbr, if it's not you must not. Since the current nero encoder makes this decision automatically (and according to the devs should never be forced), MeGUI should check after the encode whether or not HE was used via mediainfo (the latest versions will tell you if it's SBR or not) and call mkvmerge based on that. MP4 actually doesn't signal HE, and while the bitstream does mkvmerge doesn't attempt to parse the raw bitstream.
No, no Nero automaticly signal Backward compactible if HE-AAC used, aslo CTAAC automaticly signal when in mp4 container, for aac need only signaling.

[Blue_MiSfit]

FYI I didnt specify anything. I let MeGUI handle everything, including muxing the MKV.

[satanius]

I've had the same problem. So here it is how I've solve it: i extracted raw aac stream from mp4 using mp4box and then remuxed it with video using mkvmerge. I didn't check sbr 'couse my stream was LC not HE. After that everything was ok, sampling rate is 48khz as it should be.

[Sharktooth]

I got a bit confused... what are the exact steps to reproduce this bug?

[satanius]

Bug happens when muxing mp4 to mkv. Mp4 files produced by neroaacenc have sampling rate of 48khz, when i mux them in mkv using mkvmerge sampling rate for audio stream shown in mediainfo is 96khz. Zaeleus explained it well on first page of this tread.

[Sharktooth]

so it's a mkvmerge bug not megiu's?

[foxyshadis]

No, mkvmerge documentation is very clear: You must pass the -sbr flag if the audio is sbr (he-aac), you must not pass it if it isn't. MeGUI here appears to be always setting it without checking whether the audio is sbr or not.

To reproduce: autoencode a file with output to mkv, with audio quality set high enough (say, .45) that it writes lc-aac only. Presumably any video settings. Then look at the file info in mpc or mediainfo.

Unless you consider not checking the bitstream for the flag a bug, but mosu had his own reasons for it.

[satanius]

My audio was lc aac, I didn't encode it using megui but neroaacenc CLI. No matter if I checked -sbr in mkvmerge or not, produced mkv always showed sampling rate of 96khz. Only when I extracted raw aac and muxed it in mkv, sampling rate was correct.

[Kurtnoise]

Guys, resampling comes from the decoder side not others things.

[Sharktooth]

ok, then to fix it we need to properly finish the mediainfolib support.