IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Any way to control AAC delays introduced by Nero?
rberger
post Feb 24 2009, 02:08
Post #1





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



Guys

I have a 5.1 wav which gets delayed by 97 milliseconds after encoding with Nero, as also signaled by the resulting chapter list:

CODE
MP4Box -info 4.m4a
* Movie Info *
        Timescale 90000 - Duration 00:45:01.953
        Fragmented File no - 1 track(s)
        File Brand mp42 - version 0
        Created: GMT Tue Feb 24 23:12:18 2009

File has no MPEG4 IOD/OD

Chapters:
        Chapter #1 - 00:00:00.097 - ""

iTunes Info:
        Encoder Software: Nero AAC codec / 1.3.3.0
...


I'd really like to reduce that to a minimum, if necessary by manipulating the input stream via fade-in or whatever has an impact on the amount of those extra samples. So does anybody have an idea what actually might have an impact and how I might get a step closer to possibly zero delay?
Go to the top of the page
+Quote Post
Garf
post Feb 24 2009, 08:09
Post #2


Server Admin


Group: Admin
Posts: 4886
Joined: 24-September 01
Member No.: 13



You cannot have zero delay with any transform codec.

But to give a more useful answer, please tell us what you are actually trying to do.

Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 08:26
Post #3





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (Garf @ Feb 24 2009, 08:09) *
You cannot have zero delay with any transform codec.

But to give a more useful answer, please tell us what you are actually trying to do.


"Possibly" zero delay. Minimizing it as far as it goes would be good enough.

What I'm trying to do is syncing up Nero encoded AAC audio with AVC video in an MP4 container while not relying on edit lists. And notwithstanding possible alternative approaches, I'd still be very much interested in how a WAV stream should look like to achieve minimal (front) padding in the encoded AAC stream. Almost 100ms is quite considerable after all.
Go to the top of the page
+Quote Post
rpp3po
post Feb 24 2009, 11:56
Post #4





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



QUOTE (rberger @ Feb 24 2009, 08:26) *
"Possibly" zero delay. Minimizing it as far as it goes would be good enough.

What I'm trying to do is syncing up Nero encoded AAC audio with AVC video in an MP4 container while not relying on edit lists. And notwithstanding possible alternative approaches, I'd still be very much interested in how a WAV stream should look like to achieve minimal (front) padding in the encoded AAC stream. Almost 100ms is quite considerable after all.


Handling encoder delay is a common task since the old days of digital video production. Any DVD mastering engineer had to include an offset for the AC3 track from the beginning. So it would be better if you just integrate this necessity into your workflow somehow instead of trying to 'fix' the audio stream itself.

WAV would be zero delay.
Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 13:41
Post #5





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (rpp3po @ Feb 24 2009, 11:56) *
So it would be better if you just integrate this necessity into your workflow somehow instead of trying to 'fix' the audio stream itself.


Sure. It'd still be interesting to know if the delay could be kept within bounds. As this certainly is a Nero implementation detail and the encoder not very verbose on top, I'd hoped for somebody with more intimate knowledge maybe sharing some insights here. Which could be just gained from testing and experience as well, of course. Thanks anyway.
Go to the top of the page
+Quote Post
rpp3po
post Feb 24 2009, 13:49
Post #6





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



I think the encoder delay should be a constant for any Nero encoder version and profile. So if you always add -97ms to your muxer, you should be fine.

However, I agree that 97 ms seems quite much and not the least necessary. It's more than four AAC frames. But it probably wasn't a high priority as it doesn't prevent gapless playback or anything else.

This post has been edited by rpp3po: Feb 24 2009, 13:57
Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 14:56
Post #7





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (rpp3po @ Feb 24 2009, 13:49) *
I think the encoder delay should be a constant for any Nero encoder version and profile. So if you always add -97ms to your muxer, you should be fine.


For that particular WAV it 97ms, but not for any.

As an example, I've borrowed the Twin Peaks Gold Edition from a friend and thought I'd make me an AVC copy. Now, usually I'd just mux in the original AC3 stream and be happy. But his time I wanted to be smart and squeeze out a little more space with a 5.1 AAC encoding. Now, for the first three parts of the first season of the show all went well although sync seemed to be a little off. But part four was so off limits that I started to investigate the issue in the first place.

Turned out, part four has an offset of 97ms, as said, while the other three have an offset of 54ms. And I can cut and fade the WAVs whichever way I want, it'll always be the same, which is totally nonobvious to me. That looks like padding decisions where made solely based on WAV header info. And why pad, on the front, for example two seconds of total silence in the first place?

Apart from totally making no sense to me, this also means I can not use my preferred container format MP4 and muxer GPAC, because the latter implements muxing delay via edit list atoms which are not honored by all demuxers, a notable example being ffmpeg. So I can't really sync the stuff *at all* and had to use another container format, i.e. Matroska.

Now, I don't ask AAC encoders to be enablers for deficient demuxers. But as said, it might still be helpful to know if that delay could be actively influenced in any way.
Go to the top of the page
+Quote Post
rpp3po
post Feb 24 2009, 15:45
Post #8





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



The problem must be somewhere else in your tool-chain. Nero AAC encoder delay is neither dependent on the content of the file nor on wav header information.

This post has been edited by rpp3po: Feb 24 2009, 15:47
Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 16:05
Post #9





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (rpp3po @ Feb 24 2009, 15:45) *
The problem must be somewhere else in your tool-chain. Nero AAC encoder delay is not dependent on the content of the file, wether at the beginning or anywhere else.


How's that possible? I issue
CODE
neroAacEnc -if blah.wav -of blah.m4a

and Nero "neutralizes" it's padding by writing a chapter start into the m4a. That chapter start is 97ms for one WAV file, 54ms for the other.

The WAV comes from an mencoder dump and has a standard header. No complaints from Nero.

I can run the WAV through sox, which produces a file with extensible header format, and cut/pad/fade on the way at will. No complaints from sox. Then I can feed the output into Nero as well, where this time it requires "ignorelength" apparently due to the extensible header format. The delays, i.e. chapter starts, would still be the same, and remarkably so.

Now, telling me there'd be a problem in the above "toolchain" seems to be saying the WAV headers in both cases, initially coming from mencoder and in the second example from sox, were in some way corrupt from Nero's perspective. Is that what you are trying to suggest?
Go to the top of the page
+Quote Post
menno
post Feb 24 2009, 16:46
Post #10


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



The delay is different for LC, HE and HEv2. The amount for each profile is fixed in samples, so it also differs in time based on samplerate. The delays should be less then 1 AAC frame, so there is not much that can be done on the AAC encoder side.
What samplerates were the input wav files you used?
Go to the top of the page
+Quote Post
rpp3po
post Feb 24 2009, 16:57
Post #11





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



As confirmed by menno the encoder delay is a constant for each profile. So if you are using the same sample rate (what I assumed) and profile (LC, HE, or HEv2) each time encoder delay can not be the source of your problems.

97ms is more than "less then 1 AAC frame" so we should dig into why there is a chapter mark set at this point.

This post has been edited by rpp3po: Feb 24 2009, 17:00
Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 17:40
Post #12





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (menno @ Feb 24 2009, 16:46) *
The delay is different for LC, HE and HEv2. The amount for each profile is fixed in samples, so it also differs in time based on samplerate. The delays should be less then 1 AAC frame, so there is not much that can be done on the AAC encoder side.
What samplerates were the input wav files you used?


Sample rate 48K for the WAVs.

Also a correction (!!) : the 54ms files were encoded with a different bitrate than the 94ms file. So rpp3po's previous observation that, given the same encoding parameters and kind of input, the delay is always the same is apparently correct. My bad, very sorry. It's been just that much of a file juggling here, things got a little messed up.

Example info for a short clip
CODE
$ wavinfo 1.wav
File:
   Name:          1.wav
   File Size:     11730272
Format:
   Type:          Microsoft PCM
   Channels:      6
   Sample Rate:   48000 Hz
   Avg bytes/sec: 576000
   Block Align:   12 bytes
   Bit Width:     16
   Channel Mask:  0x03F
Data:
   Start:         44
   Data Size:     11730228
   Samples:       977519
   Playing Time:  20.36 sec


which - at 224k bitrate - gets encoded to

CODE
$ MP4Box -info 1.m4a
* Movie Info *
        Timescale 90000 - Duration 00:00:20.462
        Fragmented File no - 1 track(s)
        File Brand mp42 - version 0
        Created: GMT Wed Feb 25 16:23:35 2009

File has no MPEG4 IOD/OD

Chapters:
        Chapter #1 - 00:00:00.097 - ""

iTunes Info:
        Encoder Software: Nero AAC codec / Aug  6 2007

Track # 1 Info - TrackID 1 - TimeScale 48000 - Duration 00:00:20.462
Media Info: Language "Undetermined" - Type "soun:mp4a" - 480 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 6 Channel(s) - SampleRate 24000 - SBR SampleRate 48000
Self-synchronized


So to conclude this, what would those fixed padding sample amounts then be for each profile? And how many samples a single AAC frame?
Go to the top of the page
+Quote Post
menno
post Feb 24 2009, 17:58
Post #13


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



Ah I see, this is 5.1, so 224k amounts to HE AAC. 97ms ends up as 4656 samples delay for 48khz, this is correct. So I was wrong on the 1 frame or less, should have checked better wink.gif To find out the delays for other profiles I guess you will have to test, I will not post that here. Note that for LC AAC the framesize is 1024 and not 2048.
Note also that with HE AAC you cannot remove frames from the beginning without consequences. For LC AAC you could.
Go to the top of the page
+Quote Post
rberger
post Feb 24 2009, 18:24
Post #14





Group: Members
Posts: 8
Joined: 23-February 09
Member No.: 67305



QUOTE (menno @ Feb 24 2009, 17:58) *
Ah I see, this is 5.1, so 224k amounts to HE AAC. 97ms ends up as 4656 samples delay for 48khz, this is correct. So I was wrong on the 1 frame or less, should have checked better wink.gif To find out the delays for other profiles I guess you will have to test, I will not post that here. Note that for LC AAC the framesize is 1024 and not 2048.
Note also that with HE AAC you cannot remove frames from the beginning without consequences. For LC AAC you could.


OK, cool. That's good enough. As long as the padding is predictable I can cut it right off the WAV before feeding it to Nero since it's a couple seconds silence at the beginnings anyway.

Hope I didn't come across too tight guys. But it's the first time I'm trying to properly get AAC to work, plus it's about 20 more shows to encode which I of course wouldn't want to do by hand. So to script the stuff I needed to make sure I really understand the figures and rules involved. Fixing errors later on would be kind of a nuisance, especially once the AC3s got thrown away.

So thanks a lot, and sorry for the confusion along the way. You've helped me a great deal and it's much appreciated.
Go to the top of the page
+Quote Post
Straight_new
post Oct 8 2010, 10:26
Post #15





Group: Members
Posts: 1
Joined: 8-October 10
Member No.: 84435



Hi guys.
Is there any way to avoid these delays or add them at the end of the file?
Other AAC encoders does not add them at the beginning.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th December 2014 - 16:42