Interleaving every frame or every 500 ms ??

[lovecraft25]

Hi-

I currently encode my movies in DivX Pro 5.0.2 with the AVISynth 2.06 + VirtualDub 1.4.10 method. How should I interleave the audio (it's the AC3 track extrated, then converted into WAV. Then, in VirtualDub, it's encoded in MP3 160 kbps & muxed). For my past 60 movies, I always used "Interleave audio every 500 ms". But I read almost everywhere that people interleave their audio every frame.
Can someone explain me about this ?

N.B. : the advantage of using 500 ms interleave is that it gives less overhead (i've calculated this...). Here's the Excel-based bitrate calculator i've written (in french) :
www.lovecraft25.fr.st (http://membres.lycos.fr/lovecraft25/)

A+

[stickboy]

I don't know the reasons behind it, but on my system, interleaving audio every frame causes videos with MP3 audio to be choppy.

[bb]

The standard (and recommended) setting for AC3 is "every two frames". You'll find this to be the default in GordianKnot. This always worked fine for me.

bb

[alexnoe]

Well, regarding the fact that NanDub does not only store fracted multiples of AC3 frames as chunks, but even splits AC3 frames when splitting a movie, it really doesn't matter: Your files are messed up anyway, and without special code to take care of such bad files, no player could replay it properly.

You should rewrite the whole file with AVI-Mux GUI. Since it's not nearly as complex as VDub/NDub, but merely a muxing tool, I had more time to take care of creating proper files :)

[MaTTeR]

@alexnoe

Nice tool which I had never seen yet. I just muxed and split a 2CD rip with AC3 using the deault interleave values you supply but playback is slightly jerky during pan & scans. Should we continue to use the interleave values we have been using in Vdub/Nandub with your utility? I couldn't find a readme or help file anywhere.

[alexnoe]

AVI-Mux GUI always makes one "chunk" being one AC3-Frame, so another interleave value should not cause a different behaviour. The interleave value merely controls how many such chunks are stored consecutively. I've made the experience that too large AC3 audio chunks cause the file to be replayed at warp speed.

What do you exactly mean with "jerky"? I some cases, scanning through the video causes the movie to run off-sync for a short time and then resync, but I've had that behavior with NanDub files, too...

Homepage is stated on doom9's links page:
http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/index-eng.html

For mininum seek operations on the disk during normal playback, use 75 as interleave and make rec lists.
This causes the player to always read large chunks, instead of seeking between video and audio on the disc, but it might slow down scanning through the file.

[MaTTeR]

Originally posted by alexnoe
What do you exactly mean with "jerky"?
Playback is not smooth when the camera pans from left to right or vice versa in some scenes. This effect has been very common in the past when a person uses the wrong interleave values in NanDub to mux an AC3 file.

I didn't notice any out of sync problems at all though, no speedups either:) I'll do some more testing later when I get back from work. I'd love to replace NanDub with this utility for my AC3 muxing:D

[alexnoe]

I can't reproduce this (to be more exact: I don't see any deterioration compared to NanDub output :) ). What CPU are you using? It might be possible that these shitty B-frame mess up the thing a bit.
Does this effect also occur with "make rec lists" being switched off? Well, for replaying from CD, making "rec lists" was the initial idea why I made this tool...

[Zhnujm]

just tested your prog the last hour and for me it works great.

with nandub or vdub: interleave must be a multiple of 32ms to be smooth in slow panning scenes. :(
with avimux: video is everytime smooth. :)

tested on AMD+VIA+SoundBlasterLive, Intel+BX+SoundBlasterLive.
(AC3 only, of course)

[alexnoe]

One AC3-Frame is btw 32ms long :) BTW

[Zhnujm]

so does this mean that (lets say i use 75ms interleave) nandub just writes 75ms audio data every 75ms and your prog takes care of the frame size and use maybe 64ms audio the first interleave point and maybe 96ms for the next ?
(sorry if this sounds completely stupid but i dont know anything about the avi file format :) )

[alexnoe]

It's a little bit more, but you mean the correct thing.

However, my program only works on videoframe base, so that a value of 75ms would not be possible to set, unless you have a movie with a strange fps value ;)

There's another issue with NanDub: If you use NanDub to split a file with AC3, then the AC3 stream will probably not begin with a AC3 frame, but with "the 2nd half" of a frame.
AVI-Mux GUI will *not* process such streams. I haven't implemented handling of corrupted AC3/MP3 streams yet, and I won't be able to do that at the moment (semester has begun :rolleyes: )

[MaTTeR]

@alexnoe

I found the problem that was causing my jerky video playback, I had muxed a full mvie with your utility then used Nandub to cut a peice out in order to burn to CDRW and then view it on TV. Apparently Nandub really screwed up the clip somehow or another. Anyways, I burnt the entire movie I muxed with your utility and viewed it on TV wth SPDIF out...all I can say is this is fantastic! My CD drive access times are MUCH less frequent now and the playback was perfect. I see no need to use Nandub anymore and will certainly update the AC3 FAQ indicating to use your utility for all AC3 muxing. Great job man and thx for the effort.

I can only pray for Ogg Vorbis support at this point as I have no need for MP3;)

[alexnoe]

Well, NanDub ogg support doesn't work (at least not here. Not even the decode filter is loaden when I try to replay such a file), and I have absolutely no other source of information on how to get frequency, bitrate etc of an ogg stream. Neither do I know any special values for the stream header and the such.

I won't be able to add support for ogg without help :(
Note that ogg vbr might not work at all. CBR should be possible, if someone provides me with the necessary docus...
My CD drive access times are MUCH less frequent now and the playback was perfect. After I got my DVD burner, I started storing 3 movies to one DVD-R. My DVD-ROM can only read them at 2x. After encoding 3 movies with a quantizer of 3, one of them could not be replayed properly from dvd-r on very detailed scenes (Predator, when they run through the forest).
This was the moment the idea of AVI-Mux GUI was born :)

[Chibi Jasmin]

Originally posted by MaTTeR
@alexnoe

I found the problem that was causing my jerky video playback, I had muxed a full mvie with your utility then used Nandub to cut a peice out in order to burn to CDRW and then view it on TV. Apparently Nandub really screwed up the clip somehow or another. Anyways, I burnt the entire movie I muxed with your utility and viewed it on TV wth SPDIF out...all I can say is this is fantastic! My CD drive access times are MUCH less frequent now and the playback was perfect. I see no need to use Nandub anymore and will certainly update the AC3 FAQ indicating to use your utility for all AC3 muxing. Great job man and thx for the effort.

I can only pray for Ogg Vorbis support at this point as I have no need for MP3;)

Maybe wait a bit with adding this tool to the FAQ, as I cannot report good results with it.

I have tried the following settings to mux AC3 and AVI and always got choppy playback, while 96ms/96ms in Nandub worked fine:

1 fr/96 ms
1 fr/500 ms
2 fr/96 ms
2 fr/500 ms
3 fr/96 ms
3 fr/500 ms

with above settings audio plays fine, but video is choppy, also tested with rec-list and/or open-dml on/off.

with fr >3 video plays fast forward and audio is screwed! (default of 75 fr is totally out of question here, yes, I also tried that!)

I agree that in theory this all sounded good and was happy to have a tool that could make proper avi-files, but the resulting ac3-avis are just choppy...

btw: I am not using SPDIF out, but 6 channel decode with analog output from sb live. have been using 96/96 in nandub without probs till now.

UPDATE: I found a possible reason for it not to work here...I been doing my tests with ac3s saved from within Nandub (with WAV-Header then). I redid some tests with an original extracted ac3 from a dvd and it seems to work fine also with 75fr/500ms or other settings...I will continue testing and report back, if there are still problems!

But this leaves another question: I used to remux wrongly interleaved avis I got from the web with Nandub 96/96. I would like to remux them with AVIMux GUI, but I would have to be able to get the AC3-Stream without WAV-Header then...how can I extract an AC3 from an AVI without WAV-Header? Or strip the wav-header later? Or maybe it's not the wav-header, but the ac3 that is somehow corrupted on saving by nandub? Or AVIMux can be made to support these nandub-saved ac3s? Guess, you get my point...

UPDATE AGAIN: Okay, I got it...I ran the Nandub-saved wav-ac3 through BeSliced (Besplit frontend to fix the stream) and AviMux GUI could eat it, too...maybe it's an idea to add functionality into AviMUX GUI to read ac3s (and mp3s) with wav-headers properly?

[MaTTeR]

@Chibi Jasmin

Thx for the feedback and glad to hear you found the problem. You shouldn't need to add the WAV header to the AC3 files at all now. Unfortunately I'm not sure how you can strip that WAV header from your previous rips.

I mainly use SPDIF out while testing because it seems to be the ultimate test for smooth playback. So far I've tested with TB Santa Cruz and the Hercules FII with default (500/75) settings. My results are very positive indeed. Too bad we didn't have this tool along time ago:)

[Chibi Jasmin]

Well, I only got the wav-header problem when I wanted to remux existing avi-files, but as you can read above, I also fixed the problem by using besliced/besplit.

Seems to be a nice tool indeed... :-)

BTW: Any input as if 75/500 is also fine for mp3 (cbr and vbr)?

And do you use rec-list/opendml? Seems fine here with these options, but not much testing done...

[MaTTeR]

I honestly haven't tested MP3 myself since I don't really use it anymore. I would think the defaults are fine for it as well.

[Chibi Jasmin]

Okay, thanx... :-)

[Chibi Jasmin]

Originally posted by alexnoe
Well, regarding the fact that NanDub does not only store fracted multiples of AC3 frames as chunks, but even splits AC3 frames when splitting a movie, it really doesn't matter: Your files are messed up anyway, and without special code to take care of such bad files, no player could replay it properly.

You should rewrite the whole file with AVI-Mux GUI. Since it's not nearly as complex as VDub/NDub, but merely a muxing tool, I had more time to take care of creating proper files :)

May I assume that CBR and/or VBR MP3 muxed with Nandub is not screwed?

Thanx for the great tool btw :-)

[Chibi Jasmin]

maybe it makes sense taking a preload value multiple of 32ms as one ac3-frame is 32 ms?

[MaTTeR]

Chibi Jasmin,

Any idea how one could cut subs on a 2CD rip easily and have it matched up with the cut AVI files from avimuxGUI?

It's funny you mention a preload value of 32ms, I was planning on testing the same thing later today. If I understand alexnoe correctly, the interleave values most likely wont affect smooth playback though.

[Chibi Jasmin]

Originally posted by MaTTeR
Chibi Jasmin,

Any idea how one could cut subs on a 2CD rip easily and have it matched up with the cut AVI files from avimuxGUI?

It's funny you mention a preload value of 32ms, I was planning on testing the same thing later today. If I understand alexnoe correctly, the interleave values most likely wont affect smooth playback though.

Well, 32 ms or multiple of, I am just testing 320 ms...

For the subs, depending on the format there are multiple cutters and stuff available...VobSub has its own cutter and SubRip can cut SRT files...just get the length of your final avis from nandub and cut it accordingly...

[alexnoe]

too...maybe it's an idea to add functionality into AviMUX GUI to read ac3s (and mp3s) with wav-headers properly?The goal would be to make AVI-Mux GUI ignore any WAV headers in AC3 files.
The WAV headers have a granularity value, which says how big the smallest unseparateable block is. NanDub writes a value of 1 there, and at the moment, AVI-Mux GUI always relies on WAV headers. The problem is that the playback filter requires that value of 1 there, although it is stupid.
If you then use an interleave of 75, AVI-Mux GUI will make one big chunk of 3 seconds of AC3 audio, which causes replay at warp speed. So your experience is normal. I would have to add special support for AC3-WAVs.

It should not be any problem to simply remux a file. A screwed up file with AC3 sound should be possible to be repaired this way. No need to extract the AC3 streams from the file and reinsert it...

[Zhnujm]

Originally posted by alexnoe

It should not be any problem to simply remux a file. A screwed up file with AC3 sound should be possible to be repaired this way. No need to extract the AC3 streams from the file and reinsert it...


thats right , i made my test with an already nandub-muxed file without extracting the audio first and it worked perfect.

btw, i never recognised a positive or negative effect with different preload settings (but that was with nandub).

[alexnoe]

I've never recognised any effect either :D

[Chibi Jasmin]

Originally posted by alexnoe
The goal would be to make AVI-Mux GUI ignore any WAV headers in AC3 files.
The WAV headers have a granularity value, which says how big the smallest unseparateable block is. NanDub writes a value of 1 there, and at the moment, AVI-Mux GUI always relies on WAV headers. The problem is that the playback filter requires that value of 1 there, although it is stupid.
If you then use an interleave of 75, AVI-Mux GUI will make one big chunk of 3 seconds of AC3 audio, which causes replay at warp speed. So your experience is normal. I would have to add special support for AC3-WAVs.

It should not be any problem to simply remux a file. A screwed up file with AC3 sound should be possible to be repaired this way. No need to extract the AC3 streams from the file and reinsert it...


In my case, AviMUX GUI couldn't use the file without demuxing audio stream! 'Could not read from audio stream 1....reason could be bad frame headers', so I had to demux audio and video first, then strip wav-header from audio and then remux...

can you explain a bit what this granularity value is good for? Guess it's only needed for wav-files/-headers?

[alexnoe]

Ah...so you used NanDub to split the file before? In this case, you have a problem. Your file begins with the second half of a AC3 frame...as soon as I add AC3-support for WAV files, then the WAV file probably would not work either.

Mux the WAV file into your movie, and then remux the output again. I think NanDub removes the bad beginning of the AC3 stream when saving as WAV (well, for MP3, it definitely does). So first, you'll get a crap file, which will be fixed by remuxing it again and should work then.

If this doesn't work either, then I don't see a change to mux it with AVI-Mux GUI. Just do never ever use NanDub to split a file containing AC3 sound :sly:

[Chibi Jasmin]

Originally posted by alexnoe
Ah...so you used NanDub to split the file before? In this case, you have a problem. Your file begins with the second half of a AC3 frame...as soon as I add AC3-support for WAV files, then the WAV file probably would not work either.

Mux the WAV file into your movie, and then remux the output again. I think NanDub removes the bad beginning of the AC3 stream. So first, you'll get a crap file, which will be fixed by remuxing it again and should work then.

I can't quite follow you...

What I had was an AC3-AVI muxed with Nandub with 1 frame 500ms preload -> choppy...I remuxed it with nandub 96ms/96ms.

The resulting file is not accepted by avimuxgui directly. I solved this by saving video witout audio, saving audio as wav and removing wav-header, then remuxed with avimuxgui.

The file was the first cd of a movie, so at the beginning there should be no corrupted ac3-frame, I guess...

Is there any shorter way to remux a nandub file (96/96 or wrong 1fr/500ms) with avimuxgui?

while you're at it: you said 75fr interleave is quite okay, had no problems with it, you agree 320 ms preload is fine for ac3? What settings for interleave/preload would you recommend for mp3? Guess, we can use the same?

And another one: would you consider a nandub-muxed (vbr or cbr) mp3 as a correct file? Or is there any gain in remuxing it. I actually had avimux gui complain about my wav-saved and wav-header stripped vbr-mp3 (same method as above with ac3) at the END of the stream...

[alexnoe]

The first CD shouldn't start with a bad AC3 header indeed. Usually, it shouldn't be that difficult...

The granularity value is supposed to indicate the frame size of the audio stream. For divx-audio, it is e.g. 372, indicating that one divx-audio-frame is 372 bytes long.

However, it not always does. For AC3, playback simply doesn't work if you store a granularity value different from "1". That's why AVI-Mux GUI has to retrieve the correct size from the stream itself, looking into the frame header. For WAV source, it always assumes the granularity value being correct. But I think I'm going to change that as soon as I find time...

[Chibi Jasmin]

Originally posted by alexnoe
The first CD shouldn't start with a bad AC3 header indeed. Usually, it shouldn't be that difficult...

The granularity value is supposed to indicate the frame size of the audio stream. For divx-audio, it is e.g. 372, indicating that one divx-audio-frame is 372 bytes long.

However, it not always does. For AC3, playback simply doesn't work if you store a granularity value different from "1". That's why AVI-Mux GUI has to retrieve the correct size from the stream itself, looking into the frame header. For WAV source, it always assumes the granularity value being correct. But I think I'm going to change that as soon as I find time...

Well, what I got here so far is, sometimes, when the file has not been remuxed again and is the first file out of a row (with no corrupt first ac3-frame), direct remuxing works, if it's the second OR has been remuxed again, direct remuxing does not work, it shows then ac3 0 channels instead of 5 channels btw.

BTW: I read this

Originally posted by alexnoe
if you use AVI-Mux GUI, select Open-DML and NO legacy index. This will decrease the overhead by 33%, but I can't promise that every player will read it, and microsoft only released Open-DML specs 6 years ago, so they didn't manage to write a properly working DirectShow read filter for it.

in another thread...does that mean it's not safe using open-dml option? I had no problems playing the files here on my win xp system with zoomplayer...maybe it's not playalbe then under certain circumstances? Is using rec-lists safe?

[alexnoe]

Using rec lists is safe, using Open-DML *seems* to be safe. With OpenDML+Lecagy Index, I didn't encounter any bad file unless I added more than 3 audio streams. I just can't promise anything...

As to your quote: I think I posted this when someone complained about big AVI overhead, right?

[Chibi Jasmin]

Originally posted by alexnoe
I don't hope that your quote is word-by-word... it should be something like "if you use AVI-Mux GUI and select Open-DML, but no Legacy Index, then the overhead is decreased by 33% etc"

Using rec lists is safe, using Open-DML *seems* to be safe. With OpenDML+Lecagy Index, I didn't encounter any bad file. I just can't promise anything...

It actually is word-by-word...might be bit out of context, though...so there's no directshow filter problem? I don't seem to need legacy index, if I understood correctly...

I had no problems with opendml (no legacy) and rec-list, just want to be sure...

quote is from here http://forum.doom9.org/showthread.php?s=&threadid=31351 btw

I understood it correctly, that benefit of using opendml is smaller files (less overhead), although I am muxing files < 2GB (700 MB = 1CD)!? Otherwise I wouldn't bother with opendml...

[alexnoe]

*Argh*, I have editted my post while you answered, in case someone is confused :)

The fact that Open-DML works only with less than 4 languages is a DirectShow bug, and I'm sure these problems with PCM audio if no legacy index is present is a DirectShow bug as well.

[Chibi Jasmin]

Okay, so opendml *IS* safe (except for more than 3 lang. and pcm)? Had no DShow probs here...?

[alexnoe]

Yes, I'd say it's safe. But you will only gain a few megabytes.

[Chibi Jasmin]

Okay, fine...thanx again!

[Chibi Jasmin]

What still confuses me....with nandub/vdub you get smaller files with greater interleave values...this is not the case with AVIMux GUI, why is that???

[alexnoe]

Overhead is 24 bytes per chunk (for standard AVI). Large audio interleave values in NanDub will create large audio blocks, causing less chunks and therefore less overhead.

AVI-Mux GUI doesn't create large chunks for AC3, since it seems to cause bad files. At least here, they replay at warp speed then. For MP3-CBR or other CBR formats, AVI-Mux GUI will also create such large chunks.

[Chibi Jasmin]

I didn't fully understand this...but I assume the resulting avis are valid, aren't they? :) As you say 'seems to cause bad files'...maybe there's also a way to create valid ac3-avis with less chunks? Well, who cares, if it works, the way it is...but as it works with cbr mp3, I thought, I might ask....what's the deal with vbr-mp3?

[alexnoe]

Yes, the files are valid in theory, they just don't play properly on my system. IMHO this is a bug in the playback filter. They way of interleaving should not be able to affect the speed the stream is replayed at.

For MP3-VBR it is required that one frame (for 48 kHz: 24ms)
is one chunk. Otherwise scanning through the file won't work (if you scan through such a file, then the correct position within the audio stream will be found by calculating the number of the required chunk, assuming that every chunk has the same length in time. E.g. if you seek to 1h:00min:00sec, then chunk nbr 150.000 will be loaded).
So the number of chunks, and therefore the overhead, will be constant, regardless what audio interleave you set. A different audio interleave will only affect the amount of seek operations on the cd drive during playback.

[Chibi Jasmin]

I thank you very much for all the explanations... :-) Thanx for your patience with me...

btw I have the same warp-speed effect with large interleave and ac3...

[Chibi Jasmin]

Would be great, if you could oneday add support for remuxing Nandub-files directly (as I said, if a large file has been split with Nandub, the resulting smaller files can't be remuxed directly with AviMux GUI except for the first one, because of this audio stream error thing...) without first extracting audio (then strip wav-header) and video...

[alexnoe]

What I have to add is resynchronisation, i.e. finding the begin of the next frame in case of a bad (or missing) frame header. Not this week (to time for such stuff), but somewhen :rolleyes:

[Chibi Jasmin]

Fine...looking forward to that...btw: Does all you have said about Nandub screwing up also refer to latest Virtual Dub V1.4.10? As you probably know you can mux ac3s with wav header also with Virtual Dub...does it also screw up frames and stuff like you described it for Nandub?

[alexnoe]

I haven't tried it, but it should.

[Chibi Jasmin]

Thanx...what I am still curious about is (sorry to ask, but I don't fully understand all this about chunks and stuff)...as Nandub ac3-files work fine with 96 ms preload / 96 ms interleave, does it also make screwed files with these settings? And what about files that have first been muxed with Nandub default 1 fr interleave 500 ms preload (-> choppy playback) and then been remuxed with Nandub to 96ms/96ms?

Reason I ask is, I often get these wrongly muxed files and remuxed them simply to 96ms/96ms with Nandub without probs so far.

Now AviMUXGui sounds tempting, but remuxing the files (except always for the first CD) with AviMuxGUI requires demuxing audio and video separately and stripping wav-header before...sometimes (okay, tell me not to use these files, but...) extracted audio-streams are somehow screwed, then neither BeSplit, nor AC3Fix or StripHdr or whatever can deal with it, but simply remuxing with Nandub works...so if Nandub 1fr / 500 ms remuxed to Nandub 96ms /96 ms is an alternative, I might stick to it for simple remuxing and only do my own avis with avimuxgui!? Well, I might as well wait for your support for remuxing Nandub-files...

[alexnoe]

The data of the AC3 streams itself is not really screwed up. The data is always the same. But the AC3 decode filter does not like it if the audio chunks contain fracted AC3 frames.

If you take a screwed 1/500 file and remux it with 96/96, then there will not be any fracted frames, that's why it works.
Such a again-remuxed file sould then be accepted by AVI-Mux GUI, is it (e.g. for adding rec lists)?

[Chibi Jasmin]

Ah, I see...enlightens me a bit...

BUT: The again remuxed (first nandub 1fr/500ms then nandub 96ms/96ms)file is still NOT accepted by AVIMuxGUI, if the file was not the first one out of a split set to begin with...

AVIMuxGUI then reports...AC3 Ch 0 (instead of 5) and Gran: 0 (instead of some other value) and doesn't work...

UPDATE: I also encountered some again remuxed avis, where even the first cd didn't work...well, maybe they cut some intro at the beginning...

It seems, demuxing audio and video is required quite often to make Nandub muxed files work in avimuxgui...

Question is...is there any need to do so? If there are no fracted frames after the nandub 96ms/96ms, is there still something screwed up that might be improved by remuxing with avimuxgui (except of course for rec-lists and opendml)?

[alexnoe]

If there are no fracted frames after the nandub 96ms/96ms, is there still something screwed up that might be improved by remuxing with avimuxgui (except of course for rec-lists and opendml)?Not as to my knowledge.

If a file reports 0 Channels (instead of being refused completely), then it does start at a frame header, but then, this header is crap. This should really never happen :scared: