96 kHz audio in HE-AAC? (7)

1 Name: Nayuki!4upeeexzKc : 2006-11-07 13:05 ID:bHZ94lzb (Image: 1280x1024 jpg, 202 kb) [Del]

src/1162926300670.jpg: 1280x1024, 202 kb
First off, thanks for bringing this excellent quality DVD rip of Nanoha in AVC/H.264! It is your contributions that make anime have higher file coverage in higher quality than any other form of entertainment (books, movies, other TV shows).

Now, I want to address the issue of 96 kHz audio in the files. I was initially quite surprised to see that they were 96 kHz. So I decoded an arbitrary episode to WAV (using foobar2000 0.8.3) and checked out its spectrogram. It turns out there wasn't any content above 17.5 kHz.

So here are some questions I have:
- Was the original DVD source in 96 kHz?
- Can anyone confirm or deny this finding?

Again, many thanks to DGz for making this possible!

2 Name: JJS«admin » : 2006-11-07 23:17 ID:wTqkG52/ [Del]

No, it turns out that Nero's "awesome" AAC encoder is a piece of crap. Here's what happened for a few tests I ran:

  • Input to encoder = 48khz WAV
  • MP4 output from encoder = 48khz AAC
  • MP4 from above -> mux into MKV with mkvmerge = 96khz AAC

I have no idea why this happened. It didn't matter whether I set the SBR/HE_AAC flag (I used AAC_LC btw) in mkvmerge or not, the MKV output ALWAYS reported 96khz. Unfortunately I didn't realize it until about a week ago when someone pointed it out in another post and now it's too late :/ If you're suffering stuttering or lag as a result you can set FFDShow (or hopefully your other favorite AAC decoder) to force a resample to 48khz. It's usually marked as "Force resample for >48khz" or something to that effect.

For A's I have switched to using FAAC to encode the audio and this has given me reliable 48khz output to match the DVD source. This confirms my suspicion that the problem lies with Nero Digital's CLI AAC encoder and not with mkvmerge. I also switched to using FAAC's "100%" quality setting rather than 128kbit ABR that I used in Nero. They both come out to almost the exact same filesize but finished episodes could vary in size by a meg or two.

tl;dr - Season 1 is screwed, I can't easily fix it with a patch but most people won't notice it if you have modern soundcard hardware (so far all of 2 (or maybe 3, hard to tell on an anonymous messageboard :) different people have complained that it caused problems). Season 2 will be properly encoded (I hope to get that rolling soon, I've pretty much finished my encoding test rounds).

3 Name: JJS«admin » : 2006-11-07 23:27 ID:wTqkG52/ (Image: 640x480 jpg, 41 kb) [Del]

src/1162963674608.jpg: 640x480, 41 kb

bah, forgot an image with the reply

(excuses excuses...)

4 Name: Nayuki!4upeeexzKc : 2006-11-09 17:35 ID:bHZ94lzb (Image: 80x80 png, 2 kb) [Del]

src/1163115346364.png: 80x80, 2 kb

What do you think of Vorbis in comparison to AAC?

I spent a few hours doing AAC encoding and listening tests today (including ABX), and the results were disappointing.

  • FAAC 1.25: To achieve 128 kb/s, "-q 70 -c 16000 --obj-type Main --tns" was used. Quality was even inferior to LAME MP3. Artifacts were unacceptable.
  • Nero Digital Audio+ 1.0.0.2:

    • LC mode was transparent to my ears above ~120 kb/s. There is no way to control the low-pass filtering. This encoder is probably unconditionally better than FAAC.
    • HE and HEv2 modes sounded extremely harsh (from the SBR) and had warbling artifacts. The harshness did not disappear no matter how high the bit rate was, even to 170 kb/s!
  • Vorbis (Xiph.Org libVorbis I 20050304):

    • In objective comparisons, Vorbis is superior to LC AAC above 128 kb/s.
    • To my ears, q 2 (91 kb/s) was almost transparent.
    • At q 1 (77 kb/s), artifacts were noticable but more pleasant than HE-AAC.
    • At q 0 (64 kb/s) and below, HE-AAC was more pleasant because Vorbis produced intense warbling and smearing of high frequencies.

These findings do not rule out the possibility for other, more efficient AAC encoders. However, they do suggest that Vorbis may be a better choice than AAC for efficient audio coding at high fidelity.

(The test music used was Pani Poni Dash - Roulette Roulette Ichijou-san Ver., a typical Jpop song with percussion and vocals. Sample rate was 44.1 kHz.)

~ Nayuki: a controversial, skeptical encoder ~

5 Name: zelrer : 2006-12-03 00:39 ID:qZ6qNT8D [Del]

If you need suggestions for Vorbis encoders I can HIGHLY reccommend the Lancer builds: http://homepage3.nifty.com/blacksword/
Choose one that fits your cpu type, oggdropXPd variant if you want "drag n drop" interface, oggenc variant if you want command line. They are highly optimised and will encode very fast, and the latest "20061110" builds are based on aotuv-b5 which I personally have no problems with and I highly recommend it.

Some default lowpass settings on aotuv-b5 builds in case you are interested:
Q1 15.8 khz
Q2 16.5 khz
Q3 17.2 khz
Q4 18.3 khz
Q5 20.1 khz

I usually go with default settings at Q4 if the source is delicate, but q2-q3 is also very good "bang for the buck" value if the source is crap anyway.
Not much else to write about, other than this I hope any of this can be useful.

6 Name: Fimbulvetr : 2007-02-21 14:27 ID:mGNjHYp8 [Del]

I know it's late, but I just have to .. :p

I just took one of your files, demuxed audio, muxed back without SBR switch (mkvtoolnix 1.8.1) - and guess what, it worked flawlessly (CoreAAC 1.0b9, which is my favorite aac decoder but can't be set to force a certain sample rate). I don't know how you did it, but you obviously failed at muxing. Or rather mkvmerge did, whatever.

7 Name: JJS«admin» : 2007-02-21 20:39 ID:0zY8AGZw [Del]

>>6
I'll bite :P

mkvtoolnix 1.7.0 which was the latest available when I did season 1 apparently had a bug that caused this whole sample rate fiasco. See this post on the CCCP forums:

http://www.cccp-project.net/smf/index.php?topic=994.msg6616#msg6616

Quote from: "mkvtoolnix 1.80 changelog"

  • mkvmerge: bug fix: AAC-in-MP4 with the LC profile was sometimes
    misdetected as having a SBR extension and an output sampling
    frequency of 96000 Hz.

And in this case "sometimes" == "every single time" for the set of conditions I muxed everything under.

Name: Link:
Leave these fields empty (spam trap):
More options...
Image: