PDA

View Full Version : AC3 Muxing: Where's the bug?


Ben Kenobi
11th February 2003, 23:36
Greetings to all members.
I'm new here, i'm sorta of a newbie in this world, but i wanna tell my experience with AC3 Muxing hopin it will help people out.
I read, and also experienced personally, that ac3-avi muxing is a real pain in the ass.

At real first, i was usin Nandub, but when i muxed my second movie (ST8: First Contact) with double ac3 stream 4ch at 320k, i found out that some scenes (the infamous pan&scan with slow movement of objects and/or camera) looks jerky. At first i wrongly thought it was simply a "too-high-CPU-load" problem, but after some searchin, i read of Nandub buggy behaviour when muxin sc3 audio. So, i decided to try Avimux GUI 1.11. After muxin again First Contact with followin option (avoid seeks, rec-list, opendml, 160/160) i found out somethin vey annoyin (at least 4 me): audio stream switch on the fly was no more possible; when i tried, all i got was REALLY REALLY jerky playback (absolutely awful) (actually i'm not sure if it is a bug, maybe it is a consequence of using reclist). Fortunately i've found a simple workaround 4 this: just stop playback (not pausin) with ESC key, then select language, then play it again. So, i've thought to myself i've to live with this weird behaviour (at least Avimux was able to correctly mux it), but then i found out another flaw: durin some testin i've done with Fotr chapter 17 (death of Boromir) muxin it with Avimux (again with double ac3 stram at 448k), i realized that output AVI would playback ALMOST perfectly, except for random jerky shot (after massive testin with any value for pre&inter possible, i think those jerky shots happens in relation to which settings you chose durin muxing: 4 example with 128/128 i got this jerkiness in some spot, while with 160/160 i got it in another spot, quite different from the previous). At this point i became pretty desperate, not knowin what to do.
Then i decided to give VdubMod a try, and found out somethin quite interestin. Using VdubMod 1.4.13.1 (31.01.03 build downloaded at sourceforge.net) and enablin AC3 frame handlin, i mux successfully both of my testin clips with particular value related to ac3 source stream.
I post here the simple math formula i used for muxin those two files, hopin that people here could test it out:

Interleave = "numbers of channel of ac3 stream" * 32
Preload = "Interleave" * 5
(I count LFE as a channel)

PLs, post any feedback you have on this topic. Thx!

alexnoe
12th February 2003, 18:09
AVI-Mux GUI uses interleave on frame- (or in 1.11.2 kilobyte-, if you want to) base! Setting 160/160 would be preload 160ms, audio after each 160 frames, which is the same as in NanDub 160ms/6400ms (or other large numbers, depending on your frame rate), which can't work.

Try the latest pre-release (=> signature!) with interleave of 250 kByte

The BUG in NanDub is discussed in several threads...

Ben Kenobi
13th February 2003, 01:54
Wow, that's pretty funny...
Thx 4 your time Alexnoe. :D

UPDATE:
Hopin to help you with your program i want to report some results of tests i made with AVImux ENG PreRelease, tryin to mux and split a movie clip. Subject of tests was xvid avi (1800Mb) muxed with 2 AC3 track 5.1 at 448k (approx 300Mb x2). The final output would consist of 3 files of approx 819Mb each.
In all tests, all options were checked (rec-list, OpenDML outpu, legacy index). I muxed the files with this settings (InLeave/Preload):
4F/800, 240K/600, 160K/800, 80K/400, 3F/600, 250K/625, 75K/500, 2F/400. All muxin operations gave an output which was perfectly synched within the first clip, hugely UNsynched within second, and slightly UNsynched within the third. 160K/800 gave the worst result, while 240K/600 lessen the error.

Eventually the file was perfectly muxed with AVImux 1.11 (default parameters). Hope this report will be of some use. :)

alexnoe
16th February 2003, 15:36
OK, I continue to receive problem reports with 2nd parts to be off sync. There seems to be a problem with the preload value.

Could you try preload of 0?

Minako
17th February 2003, 10:37
@alexnoe:

While you're at it...I read about V1.11.3 pre:

duplicate first AC3 frame if too many broken data is encountered during the stream

Is that the long awaited padding with silence (well, first frame) option, I have been waiting for? What exactly does it do (what is 'too many' broken data?

alexnoe
17th February 2003, 11:07
It padds with silence if the first frame is silent! If you make a TV capture and encode it to AC3, then the first frame will certainly not be silent, so it would padd with not-really-silence...

If sync is lost in the stream, it will resync, as always. It counts the number of lost bytes, and as soon as the size of one frame is reached, it inserts a copy of the first AC3 frame of the stream

Minako
17th February 2003, 15:58
Originally posted by alexnoe
It padds with silence if the first frame is silent! If you make a TV capture and encode it to AC3, then the first frame will certainly not be silent, so it would padd with not-really-silence...

If sync is lost in the stream, it will resync, as always. It counts the number of lost bytes, and as soon as the size of one frame is reached, it inserts a copy of the first AC3 frame of the stream

Sounds great!!! Thanx for that nice feature...sure, if first frame is not silent, it does not pad with silence, I got that...would it be possible to hardcode some silent frames (for standard bitrates/number of channels) into AviMuxGUI for use, instead of the first frame, if possible?

alexnoe
17th February 2003, 16:19
I could extract some silent frames from existing files (at least 192/2.0, 384/5.1 and 448/5.1), but using the first frame is *much* easier...

Minako
17th February 2003, 16:33
Originally posted by alexnoe
I could extract some silent frames from existing files (at least 192/2.0, 384/5.1 and 448/5.1), but using the first frame is *much* easier...

Yeah, sure...it's fine the way it is...but if you ever feel like inserting the silent ones, don't hesitate :)

Minako
18th February 2003, 09:53
@alexnoe: One more thing...does it still report, where it encountered a broken ac3-stream, and now also where it inserted a full new frame (the first one)?

alexnoe
18th February 2003, 10:13
It only reports broken stream positions at the moment, but that will be updated.

Minako
18th February 2003, 16:14
Originally posted by alexnoe
It only reports broken stream positions at the moment, but that will be updated.

Happy to hear that!

Minako
21st February 2003, 15:51
Originally posted by alexnoe
I could extract some silent frames from existing files (at least 192/2.0, 384/5.1 and 448/5.1), but using the first frame is *much* easier...

I just saw the new Doom9 DVD-9 -> DVD-5 full backup guide using Scenarist NT features a download for some audio dummy files...maybe you can make use of these, if you still consider hardcoding silent frames...

alexnoe
22nd February 2003, 21:38
What's up with that DTS fill file? I doubt that one needs 185 kBytes to code 10ms of DTS silence

Minako
25th February 2003, 10:12
Well, I thought you might cut out one frame...but there are probably other sources for you as well, maybe a dumb idea...sorry...

alexnoe
25th February 2003, 10:57
Of course I could :p

alexnoe
25th February 2003, 15:36
BUG ! :scared:

When using OpenDML output with AC3, the suggested buffer size will be written wrongly to the file.
While BSPlayer pukes on such files, others don't.
Well, maybe the word "to suggest" has become another meaning :eek:

I've uploaded a new pre-release. This is a release candidat. I'll now play around with a load of files and just see if all settings do what they are supposed to.
Please do the same ;)

Loading silence from external files or the such will be added later.
This time, I intend to provide a stable version, which does not have to be followed by a pre-release, fixing major bugs just a day later!