Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Any way to control AAC delays introduced by Nero? (Read 10566 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Any way to control AAC delays introduced by Nero?

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: [Select]
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?

Any way to control AAC delays introduced by Nero?

Reply #1 –
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.

Any way to control AAC delays introduced by Nero?

Reply #2 –
Quote from: Garf on
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.

Any way to control AAC delays introduced by Nero?

Reply #3 –
Quote from: rberger on
"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.

Any way to control AAC delays introduced by Nero?

Reply #4 –
Quote from: rpp3po on
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.

Any way to control AAC delays introduced by Nero?

Reply #5 –
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.

Any way to control AAC delays introduced by Nero?

Reply #6 –
Quote from: rpp3po on
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.

Any way to control AAC delays introduced by Nero?

Reply #7 –
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.

Any way to control AAC delays introduced by Nero?

Reply #8 –
Quote from: rpp3po on
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: [Select]
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?

Any way to control AAC delays introduced by Nero?

Reply #9 –
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?

Any way to control AAC delays introduced by Nero?

Reply #10 –
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.
 

Any way to control AAC delays introduced by Nero?

Reply #11 –
Quote from: menno on
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: [Select]
$ 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: [Select]
$ 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?

Any way to control AAC delays introduced by Nero?

Reply #12 –
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  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.

Any way to control AAC delays introduced by Nero?

Reply #13 –
Quote from: menno on
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  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.

Any way to control AAC delays introduced by Nero?

Reply #14 –
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.