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:

[Chibi Jasmin]

Well, this happens quite often here... :-) Also on a file (second cd again, but remember also some first cds have this) that has (probably) been muxed directly into 96ms/96ms without the intermediate 1fr/500ms.

Any chances to investigate on this? As Nandub shows these files having 5 channels 48000 Hz as it should be...maybe something still is screwed after remuxing the fracted frames from a 1fr/500 ms nandub mux into a 96ms/96ms one??? And splitting also screws something?

Originally posted by alexnoe
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: )

Well, maybe it's this issue? I never got a file that is totally rejected, they were all opened, but in case of audio chan 0 they were not processed...there must be a fracted frame at the beginning from the split process that is not removed by remuxing with 96/96 is that possible? I even have the feeling that even with direct 96/96 muxing nandub produces fracted frames when splitting, what do you think?

UPDATE: I ran some of the files making problems through Graphedit, saving the AC3-output of the AVISplitter directly to a file with dump filter...then ran that ac3 through BeSliced and always got an output like that:

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : D:\Eigene Dateien\CD2.ac3
[00:00:00:000] | Output Prefix : D:\Eigene Dateien\CD2_Fixed
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 382 bytes
[00:54:30:208] | Writing D:\Eigene Dateien\CD2_Fixed01.ac3
[00:54:30:208] +---------------------
[00:54:30:208] Operation Completed !
[00:00:13:000] <-- Process Duration

the after XXX bytes value actually differed from file to file...this also happened on a file that has been muxed to 96 ms / 96 ms directly and then split.

So it seems, all we have to deal with is the 'fracted frame at the beginning of nandub-muxed files' issue. Question is: Can you simply add some code to delete the corrupt frame at the beginning, or do we ran into av-sync issues then (what does the ac3-playback filter do with the corrupt frame is the question I guess)?

[MaTTeR]

alex,

I've come across a problem this morning and I've yet to figure it out. First of all, I noticed that if I deleted the config.ini file and then let avimuxgui recreate one that the settings don't seem to be the same defaults as I recall seeing the first time I used this app some days ago. Can you confirm?

Recreated config.ini-
[config]
format=%s (%d).avi
maxsize=2000
audiointerleave=75
preload=500
maxframes=0
maxchunksize=0
openfileoptionsflags=0
opendml=1
reclists=1
avoidseekops=1
usemaxsize=0
makelegacyindex=0

Original defaults from config.ini-
[config]
format=%s (%d).avi
maxsize=798
audiointerleave=75
preload=500
maxframes=0
opendml=0
reclists=1
avoidseekops=1
usemaxsize=0
makelegacyindex=0
maxchunksize=2000
openfileoptionsflags=299

Notice the differences, I'm pretty sure the first time I used the app that Open-DML was not turned on by default.

Edit- I can also confirm the problem with muxing a 2nd part of the movie that was done in Nandub. For now it seems we have to manually demux the 2nd part, run AC3 through AC3fix and then let avimuxGUI remux.

[alexnoe]

@Chibi: I've no idea what the filter does with these half frames. Removing such half frames should be no problem. AV-sync should be affected less than 32ms, so you won't notice the difference.
For values of 17-32, you can set a delay of +32ms in order to get it below 16ms.

@Matter: My AVI-Mux GUI doesn't activate Open-DML as default :confused: This should be the standard settings:
[config]
format=%s (%d).avi
maxsize=2000
audiointerleave=75
preload=500
maxframes=0
maxchunksize=0
openfileoptionsflags=0
opendml=0
reclists=1
avoidseekops=1
usemaxsize=1
makelegacyindex=1

There was a bug in the standard setting creation some time ago...

[Chibi Jasmin]

I made the following experiment...

I took a movie consisting of two files (cds), first file works fine in avimux, second file doesn't probably because of splitting and corrupt first ac3 frame.

I then joined the two together in VDub (96ms/96ms) with append function...the resulting file FULLY worked in AviMuxGUI.

So if there's one half of an ac3-frame at the end of the first file and the second half of that frame at the beginning of the second file, this particular frame is either reconstructed in the process of joining or deleted, I don't know.

But this got me the idea, that it should actually be possible to even keep this frame, if AviMux would support selecting more than one input file and could reconstruct the frame from the first and second file! At the moment, this does not work, because it still errors on the second file, when adding both...but if there's special code for that!?

[alexnoe]

rotfl!

Load both files, mark them with ctrl+left-click and add video source :)

[Chibi Jasmin]

Originally posted by alexnoe
@Chibi: I've no idea what the filter does with these half frames. Removing such half frames should be no problem. AV-sync should be affected less than 32ms, so you won't notice the difference.
For values of 17-32, you can set a delay of +32ms in order to get it below 16ms.


Well, sure, but it leaves a non-perfect feeling :-) Maybe look into the above post and my idea about even reconstructing that one screwed frame...

btw to know, if it's 17-32 I would have to know the size of an ac3-frame, as besplit only reports the number of bytes it has skipped not the duration...

[Chibi Jasmin]

Originally posted by alexnoe
rotfl!

Load both files, mark them with ctrl+left-click and add video source :)

I got two options:

1. Loading the two files, then adding one after another... result: Error Message about bad audio in second file.

2. Loading the two files, then marking them both as you said and then add -> avimuxgui crashes!

[alexnoe]

It shouldn't crash... *argh* I'll have a look at this

[Chibi Jasmin]

Well, it does not crash, if I try to join files, that do not fit together, in that case it spits out the 'cannot append' message... :-)

It was a nice option, if it worked, would help in all the cases, were the first cd is not screwed at least...but still we need the code to take care of the very first corrupt ac3-frame, if there's one in the first cd...

Anything I can do to help you investigate this crash?

[alexnoe]

Ah...now I know: It cannot append because it thinks the audio stream of the second file to be different from the audio stream of the first file :angry: Normally, it's not possible to append such streams, but in this case, they are not different :rolleyes:
At least, I now know what to do...I just don't know exactly when to do it :scared:

I will add an option which disabled check if ac3 audio streams are "compatible"

[Chibi Jasmin]

Well, fine...you now got 2 things on your to-do-list :-)

1. Add code to deal with one corrupt ac3-frame at beginning or end of a file.
2. Fix this join thing and if possible even keep the frame that has it's first half at the end of one and its second half at the beginning of the following file.

You would make at least one girl happy by doing this ;)

[Chibi Jasmin]

Originally posted by alexnoe
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).

Does Nandub at least do this correctly?

And what about MP3-CBR?

[alexnoe]

Yes, NanDub seems to handle MP3-VBR very well (btw AVI-Mux GUI does not handle MP3-VBR 44.1 kHz. Only 48 kHz works).

NanDub handles MP3-CBR as if it were VBR. This is no problem either.

Preserving the splitted AC3 frame is not a problem at all.
The other thing is more difficult

[Chibi Jasmin]

Okay, fine...thanx for explaining...and about that being difficult: I put all my trust into you, you'll make it! :D Have fun...

[alexnoe]

I've now produced some NanDub crap files. I can reproduces the 0-channel issue, but not the "cannot append..." message :confused: In fact, when the number of channels is displayed, then it is derived from the first frameheader (and if this is bad, it will show a crap value), while when checking if 2 files can be appended, then the only AVI stream headers are checked.
Nevertheless, I'll find out what the problem is.

[Chibi Jasmin]

'Cannot append´ only appeared, when I tried to join two totally different avis (different resolution or whatever). In case of the 0ch thing and trying to join, it is as described above: selecting both and clicking add -> crash..adding one after another -> audio error message...

[alexnoe]

Ah...so I must've misread you posting. I've already found a place which might've caused a crash and have fixed it.

Can you read some German? In this case I would not have to compile 2 different beta's for testing purposes :sly:

[Chibi Jasmin]

I can read German perfectly :-) Gimme your beta ! :)

[alexnoe]

Not ready yet; i'll post when it is (btw that's why i like it if people write their location into the profile...)

[Chibi Jasmin]

Yeah, okay, no problem...I'm not always at the comp, so once I get it and have some results I'll post back...would be nice, if you add some explanation then, what is supposed to be fixed (corrupt frame handling and/or joining avis etc.) Thanx for your work :)

One idea: If you make the code for a corrupt ac3 frame at the beginning of a movie, wouldn't it be nice to automatically add the correct delay according to the size of the corrupt frame? As I think one half frame at the beginning can't be reconstructed, or can it? So when deleting, the delay comes handy...just to make things perfect... :D

[alexnoe]

At first, I'll make it work at all...then I'll think about comfort :)

[Chibi Jasmin]

Sure :) In case you spit out how many bytes out of a total of how many have been discarded, I'd also be happy with setting the delay manually then... :D Great you find some time to work on this.

[alexnoe]

http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/Pre-release/

This should now be able to append to files if the AC3 frame at the beginning of the 2nd file is splitted. It does not take care of bad first files.

[Chibi Jasmin]

Originally posted by alexnoe
http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/Pre-release/

This should now be able to append to files if the AC3 frame at the beginning of the 2nd file is splitted. It does not take care of bad first files.

It works as described! Does it preserve the splitted ac3 frame in the middle (combine the first half of the frame from the end of first file and the second half of the frame from the beginning of second file into one frame)? Or does it simply delete it?

BTW: When you try to add a file that is corrupt at the beginning, it now pops up an error message, instead of displaying 0 channels, but I guess you know that already :-) Thanx so far...

[alexnoe]

It preserves the splitted frame.
Showing 0 channels was a bug.

[Chibi Jasmin]

Great stuff...thanx a lot...

if you now make it able to deal with split frames at the beginning (and maybe preserve the frame, if possible (guess not, or?) or do the delay thing manually or automatically), we got a great tool for ac3-avi handling!

[Chibi Jasmin]

I saw your new prerelease version from October 30th. What's new? Any tests I can do?

[alexnoe]

MP3's should now work even if the first frameheader is corrupt. Maybe I can add the same for AC3 today.

[Chibi Jasmin]

Great! What does(mp3)/will(ac3) do it with the first corrupt frame? Guess, it will just kill it?

Will there be any output of how many bytes/ms have been killed so one can think about playing with audio delay and stuff? Maybe even automatic suggestion?

You know what I mean, as always thanx for your continued effort...

[alexnoe]

It just kills the corrupt beginning of the file.
At the moment, it doesn't output that, but I'm going to add this as well.
Note that you will only be able to delay AC3 for +/- 32*n millisec, and MP3 for +/- 24*n millisec.

[Chibi Jasmin]

Originally posted by alexnoe
Removing such half frames should be no problem. AV-sync should be affected less than 32ms, so you won't notice the difference.
For values of 17-32, you can set a delay of +32ms in order to get it below 16ms.


So you can only adjust audio delay in steps of 32 ms (ac3)/24 ms (mp3), is that correct? So adjusting because of cut half-frame only makes sense in the case quoted above (17-32 -> 32 delay), if I get it right...!?

How does Nandub handle ac3(mp3)-delays that are not multiple of 32(24)? Fuck up the files? *g* Or just round the values?

[alexnoe]

I don't know, but it has the two possibilities you mentioned: It can fuck up the files or round.

Adding a delay to the audio stream is nothing more than duplicating / removing audio frames. Since AC3 has audio frames of 32ms, it's impossible to add delays which are no multiple of 32ms (of course, you can decode the whole stream to 5 or 6 wavs, set the delay for the wavs (possible in steps of 20,8µs), and reencode to AC3 :p) without screwing the file.

EDIT new beta is uploaded.
For source streams from an AVI file, it now displays "Begin: <number>". This is the amount of bytes which are cut off at the beginning of the stream.

[Chibi Jasmin]

Okay, I understand...

So begin: number displays the amount of bytes that have been cut off the first audio frame? We still need to know then how many bytes total a complete frame has? Well, will take a look at it...

[alexnoe]

The amount of bytes in one frame is the granularity.

[Chibi Jasmin]

I see....

So to sum it up: If we have

Begin > Granularity/2

we should add 32 ms delay for ac3 and 24 ms for mp3, right?

So all we should do is test functionality now, right?

[alexnoe]

For MP3, the granularity will be shown as "0", since the frames are not of constant size. You can only guess then.

For AC3, you're right.

[Chibi Jasmin]

Only true for vbr-mp3? Or maybe also for cbr-mp3?

[Chibi Jasmin]

I still have one problem with the program btw...if I open a video and add it, then remove all and open a video again and add it...then remove again and so on....repeating that a few times often leads to crash on file open after several files....

[alexnoe]

For MP3-CBR, granularity is 1 (this doesn't make sense in any way, but it seems to be required for proper replay. When writing the correct granularity into the header, replay doesn't work :confused: ). This will cause AVI-Mux GUI to add fracted frames if you set a delay!

I recommend setting the "force VBR for MP3 streams" option in the advanced options window if you intend to set a delay for an MP3 CBR stream. The stream will then be treated as VBR

[Chibi Jasmin]

okay, fine...maybe add some kind of protection then for granularity of 1 to avoid fracted frames?

Would you mind to explain what exactly the three mp3-cbr options in advanced dialog do? I played around with them but didn't get to it...

[Chibi Jasmin]

I don't know, if this intentional, but in the version, that displays the begin numbers, joining AC3-AVIs, where second file has a split ac3-frame at the beginning is broken (same old error message), worked in the version before!

[alexnoe]

About MP3-CBR:

These options are only for MP3 files, not for MP3 streams in AVI files.
There is no easy way to determine whether a MP3 file is CBR or not. The only way is to look into every single frame header (150.000 per hour) and check if all bitrates are the same. This requires to read the whole file.

At first, AVI-Mux GUI only checks the first 1000 frames. If all bitrate values are equal there, then there are 2 possibilities: (1) automatically check the whole file (2) ask the user if the whole stream shall be checked.

If you select "never", then all MP3 source files are assumed being VBR, without checking if they are CBR.
I don't know, if this intentional, but in the version, that displays the begin numbers, joining AC3-AVIs, where second file has a split ac3-frame at the beginning is broken (same old error message), worked in the version before! it should still work :confused: , and I don't get this error...does it report the correct number of channels etc for both files?

[Chibi Jasmin]

thanx for explanation...

About the joining issue.

Yes, it does show the correct number of channels for both parts of the movie...but when marked both with ctrl left click and added and then clicking start it fails in the middle of the file with audio stream error...

UPDATE: Damn, I am confused now...I now have versions from 26-oct, 30 oct and 31 oct failing!? I will see, what is going on and report back...

Originally posted by Chibi Jasmin
I still have one problem with the program btw...if I open a video and add it, then remove all and open a video again and add it...then remove again and so on....repeating that a few times often leads to crash on file open after several files....

Don't miss this one...although it's of minor importance...

[alexnoe]

About the crash: Certainly a memory leak. These are hard to track down...

An audio stream error...it doesn't do that here, really. What are the begin-values of your files?

[Chibi Jasmin]

Various values, always < granularity...but...I had the 26-oct version working, now it doesn't anymore...with same test files? Strange, I am confused...still testing...

okay, well, maybe you have to check 'don't check ac3s before joining' in advanced options? I will try that...

UPDATE: Okay, that's not it...I also tried unchecking open dml and rec-lists??? What is going on here??? Sorry for confusion I don't get anything at the moment...

[alexnoe]

That can't help.
Are you sure that your files are really "split" (and that there is no frame duplicated or missing)? If not, then I'd have to add resynchronisation...

[Chibi Jasmin]

They are split with Nandub and have AFTER THAT been remuxed to 96ms/96ms...but I reported that working...must have used other files? Can't remember....I can't get it to work at the moment...strange...will try some other files...

[alexnoe]

OK, i'll add resynch capability. I'm sure that one small part of the stream was lost.

[Chibi Jasmin]

yeah, seems so, I have it working now again on a stream, that has directly been muxed to 96ms/96ms with nandub and split...

What will resynchronisation do exactly? Would be happy to understand!

UPDATE: I also found a file that has been REmuxed with nandub from 1fr/500ms to 96ms/96ms and still worked with AviMuxGUI, but most that have been treated that way don't work, so there really seems to be an ac3-frame lost or something like that...how will your resynch deal with that? It shouldn't of course screw a/v-sync...just leave out one frame should be possible? or duplicate one to fill the gap?

[alexnoe]

At the moment, AVI-Mux GUI searches for the first frame header in an AC3 stream, but as soon as it finds one, the whole stream but be valid from then on.
Resynchronisation will search for the next frame header if there's an error in the middle of the stream.

[Chibi Jasmin]

I see....and how will it fill the gap?

[alexnoe]

It can't. Some of NanDub's crap output is beyond repair :devil:

[Chibi Jasmin]

But is has to put something in there, instead of just cutting out an ac3-frame, as this will screw a/v-sync (especially, if it happens more than once). You would have to put up a 'blank' frame, just leave out one frame , if possible!? Or maybe duplicate the frame before....wouldn't you?

[alexnoe]

Duplicating the same frame would sound weird, to express it carefully.
If this happenes several times in one movie, then the file is crap and not repairable.

[Chibi Jasmin]

Can't something like a 'silent' frame be inserted? You are really going to just destroy av-sync? Or did I get something wrong...if one ac3-frame in the middle is corrupt or missing, what will this resynch option do exactly?

The point is Nandub/Vdub can handle their own files (also rejoin them), however crappy they might be before and after...

[MaTTeR]

Wow...between the 2 of you, this thread has really spread wings:D

Possibility to summarize all this information somewhere in the readme file or web page after you have got it all straight. This is certainly one of the most comprehensive threads I've seen on muxing/interleaving.

[alexnoe]

If only one frame is deleted, then the A/V deviation will not be more than 32ms -> you won't even see it. Really not.
A silent frame would be possible (I could take the first frame of the first file; this one should be silent).

It would be no problem to process all these files if i'd just take AC3 as a bytestream and create files as terrible as what NanDub generates. The point is that I refuse to do so.

[Chibi Jasmin]

I understand that you refuse to do it like Nandub/VDub do...but please think seriously about some 'silent' or 'blank' frame feature....I already have a 3 cd-movie, that has this problem, would sum up to 64 ms delay for the skipped frames and maybe some more for the screwed frame at the beginning...

[alexnoe]

OK, the german pre-release can now resynch AC3 within the stream. Later versions will output info on where any issues were encountered, the current one doesn't

As to summerize this thread:
Not today :p We have Blair Witch Project on TV now, and from 0:00 to 3:15 (yes, a.m.), 4 episodes of "Buffy" :)
I also have to prepare some things for university...

I could start setting up an explanation of the AVI file format, but as already said, not today :D

If it sums to -64ms, then set a delay of 32, so that it shifts from -32 to +32 during the movie.

[Chibi Jasmin]

Okay, if I understand correctly this version now just deletes corrupts frames in the middle and everytime cause a 32ms delay issue...is that correct? Later versions will tell you, where they caused that problem?

I really hope you get into that 'silent' frame thing...thanx for everything so far, enjoy your tv show then...

[Chibi Jasmin]

again a new version yesterday? What has changed?

[alexnoe]

There was a typo in the source (a wrong number), and I was not sure if this has already been where when I compiled the that version. So I recompiled and uploaded again.

[Chibi Jasmin]

Yeah, okay....thanx...

[MaTTeR]

Chibi Jasmin,

Have you noticed slow seeking times? Acaila mentioned this to me a week or so ago and I hadn't noticed it until now. I'm just using the default interleave values of 500/75 and indeed the seek times are slow. I also noticed the same problem when muxing MP3 files.

alexnoe,
Would it be difficult to add a demux function to the GUI also? It would be nice demux these AVI files that were muxed incorrectly with NanDub. For now I'm manually doing it with Nandub. Just a thought:)

[alexnoe]

MP3 and AC3 can be demuxed. Right-click onto the audio stream...
Other formats would require writing a WAV file, which I won't add unless I have time to.

The slow seek times are not understandable to me :confused: That doesn't mean that they are not there though :rolleyes:

[MaTTeR]

I knew about demuxing the AC3 and MP3 file but I dont see an option to demux the video stream by itself.

[alexnoe]

oops...that doesn't work indeed. You can't select "no audio stream" at the moment :(

[Chibi Jasmin]

Originally posted by alexnoe
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.

Isn't this 'slow scanning' what Matter might mean with 'slow seeking'? :)

I didn't have problems with slow scanning though...

BTW: Are you still considering the 'silent frame' thing or any other solution, instead of simply killing one frame, where one or both parts of one complete frame are corrupt/lost?

[alexnoe]

I am considering it, just while preparing the next "Hardwarepraktikum", searching for material for 3 speeches I have to give in english, learning some french vocabulary (which takes slightly more time than learning the same amount in english ;) ), working on some issues with weak sectors.
I got a LiteOn 52x for free from LiteOn in order to write a review, which will consume time as well.

You see, I'm just a bit distracted from AVI-Mux GUI :p

[Chibi Jasmin]

Well, no problem, I don't wanna push you...take the time you need...thanx in advance!

[Chibi Jasmin]

BTW: Do the ac3-corruption problems with VDub/Nandub mentioned here also apply to the new VDubMod with ac3-muxing? How about mp3 in this version (vbr? cbr?)?

[alexnoe]

I doubt that VDubMod has an improved AC3 code...but I haven't tried, nor have I looked into the source.

[Chibi Jasmin]

Let us know, if you ever happen to do so or get any information on this, please...

[MaTTeR]

Originally posted by Chibi Jasmin
Isn't this 'slow scanning' what Matter might mean with 'slow seeking'? :) LOL...somehow I missed that line in this thread. I suppose that's what causing the issue then.

[Chibi Jasmin]

Yep... :-) If seeking is to slow for you (I had no issues reading from cd with 75 interleave, seeking quite fast anyway...), just lower the interleave value then...

[Chibi Jasmin]

I asked the question, now I answer it :)

From VDubMod thread:

Quote: The sources of nandub were used for MP3 (and ogg, ac3...) support, indeed. However, only the modifications of nandub concerning audio were taken. There are currently no plans to include SBC (I personnally don't feel the need for it and I find that DivX or Xvid can produce very similar results while being simpler to use...).

[Chibi Jasmin]

What's new in 07-Nov version?

[alexnoe]

Number of crap bytes at the beginning of a stream is now also shown for AC3 and MP3 files (not only streams in an AVI file) Shows now a message box when done fixed disabled progress bar for creating legacy index

[alexnoe]

http://www.plaudersmilies.de/pissed.gifVery silly bug again. That's why it's called "pre-release":
AC3 streams were not appended if they were splitted *correctly* before...fixed.

EDIT removed another bad bug today, regarding the Mode 2 - Form 2 - Reader class.

[Chibi Jasmin]

Great...if we now get a solution for corrupt frames in the middle (the silent one?) instead of simple deletion, your tool is getting near perfect...

[Chibi Jasmin]

what's new in 16-nov version?

[alexnoe]

EDIT removed another bad bug today, regarding the Mode 2 - Form 2 - Reader class.I know you want to see a better solution for concatenating NanDub crap files, but not this time :p

[Chibi Jasmin]

Well, maybe next time then... ;)

[Chibi Jasmin]

What's new in 25-nov version?

[alexnoe]

http://forum.doom9.org/showthread.php?s=&threadid=38855

[Arcon]

i'm not sure if i understand this right: if i split a movie with an ac3 audio track within nandub or virtualdubmod, it might cut ac3-frames at the wrong position within a frame. but does it mean that the files are from that point on unusable for proper ac3-playback or can i get the original, working ac3-stream if i join the files together? or asked in another way: is the nandub-cutting reversable?

second question: i want to cut my movies not based on the file-size but based on the scenes. e.g. if i'd cut at 699mb i might cut in the middle of a dialog but if i wait till 701mb i might get a nice scene change to cut. so i'd like to be able to see the movie to find the right spot. how can i do this?

btw: why doesn't avimux-gui have any file-menu? i hate drag and drop, its so complicated. keyboard shortcuts are much easier to handle.

[alexnoe]

NanDub cutting is usually reversible, as you call it.

AVI-Mux GUI doesn't have a menu because I hate that. The number of buttons will be as low as 3 in the next version....if you don't like drag&drop, you can also right-click into the source file listbox.

[Arcon]

NanDub cutting is usually reversible, as you call it.

good to hear. and thanks for the fast reply.

The number of buttons will be as low as 3 in the next version....

wow. as long as it wont have only one button labeld 'do' ;)

you can also right-click into the source file listbox.

thats ok for me, too.