Avi with AC3 why isn't there a better way?

[Arkay]

There's been a thread http://forum.doom9.org/showthread.php?s=&threadid=36094 that talks about muxing AC3 into avi (divx specifically).

I've been using nandub to interleave ac3 into avi and have found it trial and error the same as everyone else although the "recommended" settings in the audio faq do work 90% of the time, there's always one every now and then that doesn't though.

Then along comes a prog called avimux that claims to mux AC3 properly (although I'm not sure what criteria was used to judge that nandub doesn't do it right).

I've tried avimux and had great results on my encoding machine (can see the added smoothness and lesser HD/CD activity). Until I went and played it with SPDIF out. For some reason the AC3 codec doesn't switch my AMP to DD and I get a fast pulsing very loud static instead. I have to go into the codec, select stereo, then reselect SPDIF to get it to work. I don't get this problem with Nandub, all files play audio correctly when loaded although the "random" nature of nandubs interleave settings means I can and do get stuttery playback on some panning scenes on some rips. I am unable to fix this on my encoding machine (everything looks fine) but I don't have AC3 SPDIF capability to test it there. My playback machine isn't as quick but can play an avi stream with AC3 5.1 no problems if the interleave settings are right in the first place.

So, the question is. Why is the AC3 interleaving in AVI such a great mystery? Why isn't these something that can do it right, each and every time and why do avimux interleaved avi's not play properly.

My playback hardware config is:

P3 733
G400 Tv out
Sb Audigy (I know.. but it does work for AC3 with Nandub interleaving).
Intervideo codec (also tried others, same problems).

Surely there must be some explanations to all this. Why should it vary from one soundcard to the next or from one machine to the next?

If it truly can't be sorted out what is the point in divx with AC3 if we can't be gauranteed the same playback from one machine to the next. Not very future proof?

Ok.. There's my beef. Can someone please explain and can the author of avimux shed some light on why the first few frames of AC3 when used with that tool screwes playback?

There must be a way to figure out this mess. Alternately, what other formats could be used to contain divx with AC3? These problems don't occur with VOB's... Why not?

Cheers,
Arkay.

[ChristianHJW]

Originally posted by Arkay There must be a way to figure out this mess. Alternately, what other formats could be used to contain divx with AC3? These problems don't occur with VOB's... Why not? Cheers, Arkay.

There are no proper standards to use AC3 in AVI, thats the problem. AVI normally only supports audio through the ACM interface API, and there is no such thing as an AC3.ACM codec, so everybody is using his own little 'hack' to mux it in ( same as VBR MP3 ) and in the end there is no compatibility.

MCF will solve this problem finally, as AC3 audio is a part of the specs and the container is based on timestamps for each block, so syncing will be guaranteed in any case.

Please dont ask me now when you will be able to use it, the specs are in final discussion and likely to be frezed soon, and we have an alpha of Suiryc's VdubmodMCF being tested. But there is still a hell lot of work for the team, i'd like to motivate anybody to contribute, especially people with c/c++ programming skills :D .

http://mcf.sf.net

[Arkay]

ChristianHJW,

Thanks for the reply. Just checked out the link and MCF would appear to be everything that is needed. I congratulate you on getting stuck into something of this magnitude.

Good luck with the project. I'll be watching keenly for the first beta's. I'd offer to alpha/beta test for you but you probably have more than enough people doing that already.

Looks like for now I'll stick with nandub for AC3 until MCF is available.

Cheers,
Arkay.

[janosch]

Originally posted by Arkay

...Until I went and played it with SPDIF out. For some reason the AC3 codec doesn't switch my AMP to DD and I get a fast pulsing very loud static instead. I have to go into the codec, select stereo, then reselect SPDIF to get it to work.....
Cheers,
Arkay.


i have the same problem with AVImux, although all says it works better than Virtualdub_ac3 or nandub.
What you have done exactly to fix the problem, which codec, the output control of your soundcard or what ?

CU

[Arkay]

What I did to fix the problem was to go back to using nandub and hoping the interleave settings I'm using are right for a particular clip.. Of course, when I go to play it on my playback machine with SPDIF it may not be. :( Unfortunately until I get my home network finished I won't be able to test play anything without burning to CD first which is most annoying.

Cheers,
Arkay.

[alexnoe]

@Arkay:

I've received a second report about the same problem.

The criterion used to judge NanDubs interleave method was that it cuts AC3 frames in the middle.

I still have no idea where the problem comes from, but did you try AVI-Mux GUI with small interleave values (e.g. 3 frames)? Did you try both rec-lists being switched on and off?
That's not a solution, it's just a test :(

[Arkay]

I haven't tried any other settings other that the defaults which looked perfect on my encoding machine. I tested it on a panning scene that I just couldn't get right in nandub and it looked perfect. It wasn't until I burned a CD and tried it on the playback machine that I noticed the problem.

I might have a go at getting Avimux working properly when I get the network connected to my playback machine and don't have to cut a cd for every test. (I don't have a Rewritable burner unfortunately).

Interestingly though if I switched the codec back to stereo, then back to SPDIF it fixed the problem and playback was smooth. It appears to me to be something at the very beginning of the AC3 that possibly got thrown at my soundard too quickly? Maybe it has to do with the preload number. With nandub I use 64/64 or 128/128 with most rips. Maybe 500/75 caused the problem.

Cheers,
Arkay.

[alexnoe]

I have a trace. DirectShow might misinterprete the dwSuggestedBufferSize and dwInitialFrames values in the audio header.

I've adapted these values to be the same as for NanDub output (i.e. dwInitialFrames=1, dwSuggestedBufferSize = 2*AC3-Framesize).

These values do not mean anything for the SPDIF-out. If they fix the problem, then this is another thing where muxing programs have to take care of DirectShow bugs :(

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

[Arkay]

Hehe... Man.. That was quick turnaround time. If you have ICQ send me an email and I'll give you my number. Looks like you're up at the same time as me so I can maybe run some tests while we chat.

I'm about to burn a 100MB clip to test with. I've used settings of 128/128 (just to make sure about the AC3 frame size being multiples of 32). I'll go test it in a minute.

Cheers,
Arkay.

[alexnoe]

Don't use AVI-Mux GUI with an interleave of 128. I've found that this doesn't make sense.

About the multiple of 32: That is only important for NanDub.

[Arkay]

Ok.. I've run some test. Burned 7 clips to a cd with differing interleave values on a panning scene, including variations of reclist/noreclist, opendml or not, legacy or not.

All of them exibited the failing to switch to DD on the amp and the resultant static. Switching to stereo then back to SPDIF fixed it so I could check the actual panning scene with correct audio.

I found that with the SPDIF all the interleave settings worked quite nicely. Some strained the CD more than others but none were jerky (even 128/128 was good).

What I then tried was changing the default output device of the intervideo codec.

You'll be glad to know the problem seems to be related to sound card drivers and the way they pass through AC3.

I have a shitty SB Audigy. With nandub files and output set to default wave out everything works fine (except for the interleave jerkiness problems). With avimux default waveout doesn't work. Neither does any other setting either though (tried directsound) and I do get sound, without the static but in PCM, not AC3.

Also tried the cyberlink codec and got the same symptoms.
Tried bsplayer, powerdivx and powerdvd's open media file.

Nandub does something different on those first few frames that hit the soundcard driver. If you can nail what that might be you'll be laughing. Obviously this only occurs on very few soundcards and probably SB cards at that.

I'm going to look if creative have yet managed to write a decent driver. I'd be very interested to see if linux playback on the Audigy would be any better. If I can find a small drive big enough for linux I'll build a player on that one day soon and see what we get then...

Ok.. Hope that helps a little.

Cheers,
Arkay.

[ChristianHJW]

Originally posted by Arkay ChristianHJW,
Thanks for the reply. Just checked out the link and MCF would appear to be everything that is needed. I congratulate you on getting stuck into something of this magnitude.

Thanks for the motivating words mate. I just hope we are NOT stuck, and in fact it seems we are finally progressing nicely, after a long period of a 'creative break' ;) ...

Good luck with the project. I'll be watching keenly for the first beta's. I'd offer to alpha/beta test for you but you probably have more than enough people doing that already.

Thanks for the offer. In fact this is not the case, we still accept alpha testers for VdubModMCF, especially people with a bit of technical background. Just drop in on irc.openprojects.net , #mcf or #uci during the European evening hours, we will meet there with high probability.

Much more than people wanting to contribute as alpha testers we are searching for supporters of the project in general, and there is still a lot to do, even tasks that dont require C/C++ coding skills, like php coding, Java, website updating, etc. .... in fact, one of the most important motivations for me to tell people about MCF again and again is the fact that our team is sinmply too small for the big task we accepted. Any help is highly appreciated, however small it will be.

Looks like for now I'll stick with nandub for AC3 until MCF is available

Even if you would decide to join the alpha testing team, you still had to use nandub or VirtualdubMod for the time being, because the MCF files created with the existing alpha tools will not be spec compliant once we update libmcf to meet with latest specs ( which can be found here : http://mcf.sf.net/EBMLed/
), so all the old existing MCF files will be broken, non-playable files :-( .

[dvd2svcd]

OT:

Isn't there enough developers on EW's forum, huh? I mean since you've re-registered here you haven't done anything but trying to promote MCF and getting developers to join the MCF team. Don't misunderstand me, MCF is a good (albeit huge) idea. But, I'd like to see a few posts from you here on this board where you're actually helping other users without mentioning MCF. I mean, the basic idea of this forum is to help other people with their problems, not inviting developers to join any teams. I'd say that this borders to breaking rule number 5. I'd call your posts intelligent spam.

Anybody who thinks this is uncalled for just search and read all ChristanHJW's posts. It's like listening to a broken record.

[alexnoe]

The cause for the trouble is isolated. I'll add a workaround to make shitty-SB-compliant AC3 audio.

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

[Arkay]

Alex,

Excellent, thanks for the update. I'll try it out tonight when I get home from work.. Stay tuned.

-Arkay

[Arkay]

Alex,

Ok. Tried it out at home at lunch. Everything is fine.. Thanks!!
Amp switches direct to DD as we expected.

I used the default 500/75 settings and was amazed at how little the cdrom accessed to read. Awesome.. and smooth too!!

As you say this is a workaround should I wait for a stable release before I go and do all my avi's this way? Or do you mean that it's fixed and won't change in future releases?

Thanks for the help.

Cheers,
Arkay.

[alexnoe]

I don't intend to change it again, unless more reports about bad SB drivers arrive ;)

[ookzDVD]

@Arkay,

I think you should give .ogm a try,
you gonna love it. :)

[Arkay]

Originally posted by ookzDVD
@Arkay,

I think you should give .ogm a try,
you gonna love it. :)

Could you elaborate a little more for me? Is that the ogg container format? I've seen a few posts here and there but ignored them cause my brain couldn't handle any more!

I could use some clarification. I understand ogg audio is pretty good but how can you get 5.1 SPDIF with it? If ogg and ogm are even related. I've been trying to avound learning any new tools having just gone through a couple of brain numbing months of learning avs scripting, filter usage, AC3 encoding/decoding/interleaving, interlacing, NTSC Telecine and IVTC, Pal deinterlacing etc etc.. basically I new nothing about 2 months ago :-)

I still dunno if my brain is up to it yet ;)

Cheers,
Arkay.

[ookzDVD]

@Arkay,

Sure,

.ogm it's just a container which could mux many types of media,
if you want to get 5.1 SPDIF output, you can keep the .ac3 file,
and mux the .ac3 to the .avi just like nandub does without worry
about interleave setting :)

the other advantages are with the .ogm format, you can mux not just
the video (.avi soundless) and audio (.ogg / .mp3 / or .ac3) but
you even can mux the subtitle (.srt) and chapter info (which
generated by ChapterExtractor), those can't be done by (nandub).

the most powerful ogm muxer is Cyrius's Ogmuxer, which you can
get from his website : http://cyrius.bunkus.org

and for playback you should install the Tobias DirectShow Filter,
which you can download it from : http://tobias.everwicked.com

Goodluck.

[ChristianHJW]

Originally posted by ookzDVD
the most powerful ogm muxer is Cyrius's Ogmuxer, which you can
get from his website : http://cyrius.bunkus.org

Thats true for the time being, but watch out for the latest changes of Cyrius' VirtualdubMod on http://sf.net/projects/virtualdubmod . AC3 muxing is currently not working with the OGM container AFAIK, but should be soon ...

[MaTTeR]

@Arkay

I'm curious which playback filter(s) your using? If you haven't tried it yet, download Valex's AC3 filter and give them a go.

@ChristianHJW

Nice of you to turn the other cheek. LOL

@DVD2SVCD

I haven't seen anyone else complaining about the MCF promotion on here. Posts are easy enough to ignore if they don't interest you, at least they are for me. Maybe a PM to Chris would be more appropriate so the rest of us don't see the bickering and the cheap shots to EW?

[Arkay]

Originally posted by MaTTeR
@Arkay

I'm curious which playback filter(s) your using? If you haven't tried it yet, download Valex's AC3 filter and give them a go.


Hi MaTTeR,

I've tried the following:

intervideo (still using)
cyberlink (okish)
valex's (seems excellent)

I'm going to go back to valex's. I just put it back to intervideo cause i knew what to expect from it. It hasn't made any difference with regard to these problems though. For what Alexnoe and myself have found it's a problem with crappy SB drivers and/or cards.

I don't have any problem achieving AC3 passthrough. The SB Audigy test software in 5.1 mode will only give sound from front left/front right though but it is working.. My Amp doesn't lie and neither do my ears ;)

Can you tell me why one AC3 codec should be any different from any other if all it does is pass a bitstream through to an external decoder? Bloody software people just can't help but mess with things :-/

Cheers,
Arkay.

[ChristianHJW]

Originally posted by MaTTeR
@ChristianHJW
Nice of you to turn the other cheek. LOL

@DVD2SVCD
I haven't seen anyone else complaining about the MCF promotion on here. Posts are easy enough to ignore if they don't interest you, at least they are for me. Maybe a PM to Chris would be more appropriate so the rest of us don't see the bickering and the cheap shots to EW?

@MaTTer :

please, for heaven's sake, keep the peace mate. DVD2SVCD and me had a nice and friendly conversation via PM as a result of his post here ( until his mailbox was full that is ;) ), and i am sure he understands better now what my motivation is to 'promote' or 'advertise' MCF everywhere.
( Sidenote : Sorry, but i hate both expressions given above in relation to what i am doing here, f..ck i dont want to sell you anything, lol :) ... we need help badly for this big task and all i am trying to do is to raise the awareness of people for MCF, in naive believing somebody might decide to contribute to the project, in whatever form )

I have promised him to make it a bit easier now, also because some friends warned me already that users might get annoyed by the constant mentioning of something that will be excellent once its here, but is not yet available for the time being :( ...

[MaTTeR]

Originally posted by Arkay
Can you tell me why one AC3 codec should be any different from any other if all it does is pass a bitstream through to an external decoder? Bloody software people just can't help but mess with things :-/ The channel mapping problem with SB drivers seems to have been an issue for some time that's obviously not resolved as of yet. In theory and on paper the AC3 decoders should be the same because as you said they are just passing a pure stream. Now what your drivers are doing to that stream is whole other can of worms:)

@Christian
Sorry man, I'll hold my tongue. Maybe I woke up on the wrong side of the bed this morning:D

[dTb]

Originally posted by ChristianHJW
AC3 muxing is currently not working with the OGM container AFAIK, but should be soon ...

Are you talking about having to mux to avi first? Apart from that it's working great for me.:D
Btw, I'm looking forward to MCF, if I had any expertise I would probably offer to help.

[ChristianHJW]

Originally posted by dTb Are you talking about having to mux to avi first? Apart from that it's working great for me.:D

Yes. Its one of the goals of VirtualdubMod to make this unnecessary, so one can mux AC3 into OGM directly, without creating an AVI first and transmuxing this to OGM using Tobias' DShow based muxer filter.

I am not sure if Suiryc could already look at this, we talked about this briefly on another occasion when discussing how to mux AC3 into MCF, and he said he is making his way through nando's AC3 parsing code, trying to understand it .... dont know if its working with OGM now , had no time to test.

Btw, I'm looking forward to MCF, if I had any expertise I would probably offer to help.

Again, anybody can help. Of course, some coding skills ( not only C/C++, even Delphi, php and HTML ( for website ), Java etc. are welcome ) were very helpful, without them there is only alpha testing left to contribute, and this requires somebody who has good knowledge about audio/video encoding in general and has been following the project, its goals and the mailing lists for some time at least, else i would spend more time explaining why this and that is not working now, instead of writing necessary stuff ....

[Arkay]

Hi Guys,

Thanks for the responses on this thread. I have one more question though. I've been reading up on the ogm container and muxing AC3 in.

From what I've gathered here and elsewhere there is no way to mux AC3 directly into an ogm file yet. You have to still mux the AC3 in with nandub/avimux and then take the resultant avi and use oggmux to turn it into an ogm. The question I have is this. If you use nandub to mux the avi, how is it then possible for audio sync etc to work correctly in the resultant ogm? If I were to use the wrong interleave settings in nandub wouldn't I get the same problems when playing back the ogm as it appears the ogm is just a wrapper around the avi?

I haven't yet had a chance to test this with SPDIF out. I have noticed though that the resultant ogm file is several MB's bigger than the original avi. Could someone please explain this phenomenon.

If what I've been told is correct, all I have to do to get around my sync and playback problems with my AC3 avi's is to use oggmux to convert them all to ogm files? Is this correct?

Others have suggested that this method may not be terribly future proof either? I assume then that it is possible to extract the avi file back out of an ogm and convert it for example to MCF at some later point. I really don't want to have to be fiddling with my collection every time something changes. All this AC3 stuff seems to be in a constant state of flux of alpha/beta releases? I'm trying to figure out what is the best way to store my backups to reduce the amount of rework later on.

Thanks for your help.

Cheers,
Arkay.

[ookzDVD]

@Arkay,


From what I've gathered here and elsewhere there is no way to mux AC3 directly into an ogm file yet. You have to still mux the AC3 in with nandub/avimux and then take the resultant avi and use oggmux to turn it into an ogm. The question I have is this. If you use nandub to mux the avi, how is it then possible for audio sync etc to work correctly in the resultant ogm? If I were to use the wrong interleave settings in nandub wouldn't I get the same problems when playing back the ogm as it appears the ogm is just a wrapper around the avi?


.AC3 can be muxed DIRECTLY with the .AVI into .OGM ;)
just download the ogmuxer from Cyrius's web site.

and do such this command below from your command line :
c:\xvid\>ogmuxer -o test.ogm c:\movie\movie.avi c:\movie\movie.ac3

:)

[alexnoe]

@Arkay: No, you wouldn't get these problems (hopefully)! The cause for these sync issues etc is *not* a bad AVI file, but the combination of a broken AC3fromAVI-Filter and broken SB drivers! Fixing one of these would suffice to properly replay even NanDub output files.

The *data per stream* that NanDub/AVI-Mux GUI output does not differ. Only the way it is interleaved is different.

I hope that the OGMMuxer does not use broken DirectShow components to read AVI files...

About MCF: It uses Mode 2 Form 2, doesn't it? What about drives with broken firmware which don't write this correctly, such as Cyberdrive 058D?
When I have time for that, I'll upgrade Mode2CDMaker to output a RAW96R image and see if that silly drive can write that one correctly...

[ChristianHJW]

Originally posted by alexnoe About MCF: It uses Mode 2 Form 2, doesn't it? What about drives with broken firmware which don't write this correctly, such as Cyberdrive 058D?

MCF will have a mode 2 form 2 extension , but not all MCF files have to be burned that way. In fact, we dropped the idea to make our own mode 2 form 2 form when XCD was doing so excellent, we decided to use XCD simply, in close cooperation with the devs.

Now unfortunately the project has lost a bit of speed recently as poor avih is kept with other things. I recently offered to de_xt that we could maybe include the XCD mode 2 form 2 parser into the alpha MCF Dshow parser, even for other containers ( OGM, MPEG ... i refuse to support AVI with it ). Our Dshow expert, Jan 'myFUN/kromyx' Schlenker is currently working on adding video support to the MCF parser, and after that he will look into a Dshow based muxer. This doesnt really leave him with much time to look into the XCD support, but i will ask him next time he shows up on our IRC channel.

If only we could motivate a few more developers with a background in DirectShow to help XCD and MCF :( ...

When I have time for that, I'll upgrade Mode2CDMaker to output a RAW96R image and see if that silly drive can write that one correctly...

Are you by chance a developer :D ???

[alexnoe]

Are you by chance a developer ???Only in private :D At the moment, I don't even have the time to add more suggested features to AVI-Mux GUI (I need e.g. MP3 resync capability, fixing AC3 delay for appending multiple broken NanDub files, output log file, a debug mode and so on), due to the lack of time :angry:

About DShow: I have never ever used DShow in my own programs, since I've only dealt with AVI files so far, and I don't see sense in dealing with broken M$ crap (neither AVI reader nor AVI writer of DShow work as suggested by OpenDML AVI file specs).

[Arkay]

Ok, I can now mux AC3 directly into ogm files.. Thanks ookzDVD!

But the million dollar question is (and pardon my ignorance because I'm still learning all this stuff unlike you guru's ;) )

If I have muxed ac3 into avi already and I then create an ogm file from it

(A) (i.e. ogmuxer -o out.ogm avi_with_ac3.avi),

will it play back properly as apposed to muxing the audioless avi
with the raw ac3 directly into an ogm file?

(B) (i.e ogmuxer -o out.ogm avi.avi ac3.ac3).

The reason I ask is that if case (A) above is correct then I don't have to separate the video/audio from my avi files, then strip the wav headers off in order convert all my online files to the ogm format.

Please please please tell me I don't have to separate everything to achieve the results I'm getting with case (B).

Thanks again for all the advice!

Cheers,
Arkay.

[dTb]

I don't know all the technical aspects but so far I have found that it doesn't matter if the ac3 audio has been muxed with the avi prior to muxing into an ogg.
Using OGMDemuxer on such files gives you the avi and ac3 seperate.

[Chibi Jasmin]

@alexnoe: What's new in 23-Dec prerelease of AviMuxGUI?

[kauffmbe]

Where are you getting new AviMux GUI versions from? I still have the 1.10 version from the download page.

[Chibi Jasmin]

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

[Chibi Jasmin]

@alexnoe: Any info on new prerelease from 23-Dec-02?

[alexnoe]

Nothing special, but somewhen in the next few days, I'll release a new one, which will finally be 1.11 and again available in german and english. Major changes:
=> reports details on broken AC3 streams (but no padding with silence yet)
=> support for DTS
=> does no longer use the file name extension to identify the format of a file
=> when checking the available space on a drive, files to be overwritten are scanned for and their space considered available

[Chibi Jasmin]

Originally posted by alexnoe
Nothing special, but somewhen in the next few days, I'll release a new one, which will finally be 1.11 and again available in german and english. Major changes:
=> reports details on broken AC3 streams (but no padding with silence yet)
=> support for DTS
=> does no longer use the file name extension to identify the format of a file
=> when checking the available space on a drive, files to be overwritten are scanned for and their space considered available

Fine...if you ever get that ac3-stream silence thing in, well....you know... :D But it's great to get at least the details on a broken stream...

Looking forward to the new version... :)

[Chibi Jasmin]

I just read in the V1.11 changelog:

'changed interleave pattern for AC3: Now 2 AC3 frames are stored into one chunk.
This is required for some broken SB drivers to work correctly with SPDIF-Out.'

While earlier you said, large ac3-chunks are valid in theory, but they play at warp-speed and therefore you made it 1 chunk/ac3-frame...what about this change now? Please explain...I guess 1 chunk/2 ac3-frames is not considered 'large' is it? Nandub 96/96 ms muxed files also had 2 or 3 frames / chunk, if I am right and worked!?

[alexnoe]

96/96 are 3 chunks.

[Chibi Jasmin]

Isn't it 2 chunks and 3 chunks in a varying pattern? Well, anyways, that's what I wanted to know, so everything should be fine.

[Chibi Jasmin]

What I always wanted to ask...what exactly does the preload value do? Does it make sense to have a preload of 500 ms for ac3, while one ac3-frame is 32 ms (500 ms is not a multiple)? Will Axi MuxGui round up to the next multiple of 32 ms? Or does the preload value just not work that way and do something completely different?

Can someone explain, please, what preload exactly does?

[MaTTeR]

I remeber reading awhile back that preload served as a pseudo buffer but I can't verify that at all. In that same thread someone had suggested they didn't think the value was even being used when muxing with NanDub. I'll see if I can locate the thread.

[Chibi Jasmin]

Originally posted by alexnoe
=> reports details on broken AC3 streams (but no padding with silence yet)


Thought, I'd dig this one out again :D I know you're probably more busy with the dts-muxing at the moment, but PLEASE don't forget about this one...it would be such an easy solution to remux all kinds of broken ac3-streams...if one frame is corrupt, and there's a silent one inserted automatically, one would have to worry about any delay issues and stuff...I'm sure a lot of people would appreciate it...me for sure...;)

Tell me, I am impatient...yes, I am...

[Chibi Jasmin]

Originally posted by MaTTeR
I remeber reading awhile back that preload served as a pseudo buffer but I can't verify that at all. In that same thread someone had suggested they didn't think the value was even being used when muxing with NanDub. I'll see if I can locate the thread.

A buffer in DirectShow? Guess the value is at least used with AviMuxGUI? And if there's a buffer, still the question, if it allocates multiples of the frame size or not..? Would be nice, if you have some more info...good luck in finding the thread!

[MaTTeR]

Well after 7 pages of threads I wasn't able to find the thread I was thinking about, maybe too old and archived. Here (http://forum.doom9.org/showthread.php?s=&threadid=17606&highlight=preload) movmasty explains that preload is more like silence. I'd love to find a nice explination myself though, maybe alexnoe can add it to his docs as well.

[Chibi Jasmin]

Well, thanx anyway... :)

[Chibi Jasmin]

Originally posted by alexnoe
AVI-Mux GUI does not handle MP3-VBR 44.1 kHz. Only 48 kHz works

Older quote...does this limitation still apply to V1.11+ versions?

[alexnoe]

@Jasmin:
Yes. It miscalculates the framelength of 44.1 kHz MP3 frames. The deviation is more than 0.1% (acceptable is 0.001%)

@Matter: If you want me to check if NanDub uses the preload value, then i can do that. Takes me a few minutes.

[Chibi Jasmin]

Originally posted by alexnoe
@Jasmin:
Yes. It miscalculates the framelength of 44.1 kHz MP3 frames. The deviation is more than 0.1% (acceptable is 0.001%)

@Matter: If you want me to check if NanDub uses the preload value, then i can do that. Takes me a few minutes.

I see...is this an issue that is going to be fixed or is there some limitations?

Maybe you can explain, what preload is actually good for and how it is interpreted?

BTW: You seen my other question above about padding with silent frames for corrupt streams? :D

[alexnoe]

If I find out why the frame length is miscalculated, then it will be fixed.

[Chibi Jasmin]

Okay...thx.

[MaTTeR]

Originally posted by alexnoe
@Matter: If you want me to check if NanDub uses the preload value, then i can do that. Takes me a few minutes. Thx but I'm sure you have other pressing projects to work on:) I might have time this weekend to hack around and see what effect if any it has on the mux.

[Chibi Jasmin]

@alexnoe:

I just took a Nandub muxed ac3-avi with a fracted frame at the beginning (avimux gui showed a begin value of 560) and did the following two tests:

1. I demuxed the audio with VDubMod.
2. I remuxed the file with 96ms/96ms with VDubMod.

I checked the resulting ac3 (from 1) and avi (from 2) in AviMuxGui and it still showed a begin value of 560 in both cases. So VDubMod actually preserves the fracted frame at the beginning. Just wanted to let you know, as I think you stated differently, didn't you?

[alexnoe]

No, i didn't: I think that NanDub does not preserve broken MP3 parts...

@Matter: I would just have a look at a NanDub file in the Vdub hex editor...but you may prefer this: Try NanDub with 10000 preload.

Seeking on a CD should become *really* awful if this preload is really applied

[Chibi Jasmin]

Originally posted by alexnoe
No, i didn't: I think that NanDub does not preserve broken MP3 parts...

Sorry, I remembered it wrong then...but that leaves one more open question...

What happens to that broken frame at the beginning?

We used to fix wrongly muxed nandub streams by remuxing them with 96 ms/96 ms for the plain reason, that it does not produce fracted frames then (since one frame is 32 ms). But if it treats ac3 simply as a bytestream, it would start counting with that half frame at the beginning and move 96 ms further on, what would leave it right in the middle of another frame...!? And cause fracted frames all through the whole file (fracted from one chunk to another, I mean)? Or is the first half frame somehow treated special? Please let me know your findings about this...

[alexnoe]

We used to fix wrongly muxed nandub streams by remuxing them with 96 ms/96 ms for the plain reason, that it does not produce fracted frames then (since one frame is 32 ms). But if it treats ac3 simply as a bytestream, it would start counting with that half frame at the beginning and move 96 ms further on, what would leave it right in the middle of another frame...!? Right. The decode filter seem to like that somehow :confused:

[Chibi Jasmin]

Originally posted by alexnoe
Right. The decode filter seem to like that somehow :confused:

Hmm...yeah, the files worked, as we all know...this leaves us the possibility to set delays other than multiples of 32 ms...one advantage, at least...but if this works, why don't Nandubmuxed files with 500ms/1fr work (they play choppy)? I thought, it was the fact, that ac3-frames were fracted...now, I know, they are often also fracted on 96ms/96ms (re)muxed files...so that was not the reason? :confused: Any thoughts on this?

[alexnoe]

Maybe it's because of the different way they are fracted (e.g. for 96/96, you'll always have the same amount of fraction, while for 80/80 or the such, the sizes of the fractions differ)

[Chibi Jasmin]

Originally posted by alexnoe
Maybe it's because of the different way they are fracted (e.g. for 96/96, you'll always have the same amount of fraction, while for 80/80 or the such, the sizes of the fractions differ)

Yeah, maybe...so what was your reason for avoiding fracted frames in avimuxgui (and even sacrificing accurate delay control), if these fracted frames work?

[alexnoe]

(1) the beginning of a stream should not be a fracted frame, otherwise the fracted beginning cannot be replayed anyway
(2) the chunk size must be a multiple of the AC3 frame size
(1)+(2) => no fracted frames at all

[Chibi Jasmin]

Originally posted by alexnoe
(1) the beginning of a stream should not be a fracted frame, otherwise the fracted beginning cannot be replayed anyway
(2) the chunk size must be a multiple of the AC3 frame size
(1)+(2) => no fracted frames at all

(1) I see...but is its existence taken into account for delay?
(2) In case of 96ms in Nandub chunk size is a multiple of ac3 frame size. But why do you say it must be that way? Where does that come from? Well, obviously only then the files replay fine (although with fracted frames -> Nandub 96/96)

What I wanted to know, why you chose to make AviMuxGUI so that it does not create fracted frames, as the 96/96 Nandub files play fine with fracted frames...

[alexnoe]

In case of 96ms in Nandub chunk size is a multiple of ac3 frame size. But why do you say it must be that way? Where does that come from? Well, obviously only then the files replay finecrappy replay filters or soundcard drivers.
Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.

If they can't make better filters, then we have to make files which their filters can replay :sly:

What I wanted to know, why you chose to make AviMuxGUI so that it does not create fracted frames, as the 96/ 96 Nandub files play fine with fracted frames...Because it seems safe to me...

[Chibi Jasmin]

Originally posted by alexnoe
crappy replay filters or soundcard drivers.
Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.

If they can't make better filters, then we have to make files which their filters can replay :sly:

Because it seems safe to me...

Okay, let me see, if I understood...

The fact that files only play, if chunk-size is a multiple of ac3 frame size, is due to crappy drivers or filters. Right?

And AVI-Specs actually allow fracted ac3-frames (I have to admit I don't understand this nGranularity thing)? Well, they actually play fine (if chunk size = multiple of ac3framesize)...

And what about (1)? The fracted frame at the beginning...does it cause a delay in playback? Then it would have its purpose...or can it just as well be discarded?

Sorry for questioning that much, but you seem to have worked with this a lot and I (and probably many others) would be happy to understand...

[alexnoe]

Every audio stream has this nGranularity value in its header. This defines the number which each chunk size must be a multiple of.
For AC3, this value is set to 1 => each chunk must have a size which is a multiple of 1.
Setting other values (which make more sense, such as the ac3 frame size) results in unplayable files.

I don't know how fracted frames at the beginning are handled. The AVI file format does not define the behaviour, so I guess than any filter does what it wants.

[Chibi Jasmin]

Originally posted by alexnoe
Every audio stream has this nGranularity value in its header. This defines the number which each chunk size must be a multiple of.
For AC3, this value is set to 1 => each chunk must have a size which is a multiple of 1.
Setting other values (which make more sense, such as the ac3 frame size) results in unplayable files.

I don't know how fracted frames at the beginning are handled. The AVI file format does not define the behaviour, so I guess than any filter does what it wants.

Every driver and filter does what it wants :D

So may I assume, these files with nGranularity=1 are spec-compliant, even if they have fracted ac3-frames throughout the whole file? Not that being compliant means too much, though...

Now, that you explained what nGranularity is, what did you exactly mean with

Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.


?

[alexnoe]

So may I assume, these files with nGranularity=1 are spec-compliant, even if they have fracted ac3-frames throughout the whole file? YesTheoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.?`A nGranularity=1 value means that the stream can look like whatever it wants, and this must not affect playback (unless the data source, e.g. CD-ROM, is too slow to manage the seeking).

Filters which require anything else should be considered broken

[Chibi Jasmin]

Originally posted by alexnoe
A nGranularity=1 value means that the stream can look like whatever it wants, and this must not affect playback (unless the data source, e.g. CD-ROM, is too slow to manage the seeking).

Filters which require anything else should be considered broken

I'm beginning to understand. Trying to sum up:

The Nandub-files with fracted frames are always spec-compliant..but only the ones muxed with interleaving multiple of 32 ms (in this case chunk size is a multiple of ac3 frame size) play flawlessly (even, if the stream is full of fracted frames), probably due to crappy filters/drivers.

AviMuxGUI does not create streams with fracted frames for safety reasons, not because it is proven to be necessary for anything.

A fracted frame at the beginning of a stream cannot be replayed. Its influence on playback filters is unknown or may vary; it might cause a delay. <- would it be possible to find out, if it actually causes a delay in playback or not?

Please correct me, if anything of the above is wrong and/or let me know, if you have an idea how to find out, if a fracted frame at the beginning could actually serve as introducing a delay in audio playback, making setting a delay not multiple of 32 ms possible.

Thanx in advance!

[alexnoe]

You've summerized correctly.

It will be hard to find out what happenes with the fracted frame at the beginning...I do not know how to determine whether a delay of <32ms is present or not.
You could try inserting more "half" frames to get an audible delay (or not).

BUT: If it is causing no delay, then the file would replay fine at the beginning, but would run off sync as soon as you seek (seeking in the audio stream of an AVI file is only based on "time / bitrate")

[Chibi Jasmin]

Originally posted by alexnoe
96/96 are 3 chunks.

Okay, the below quote might be crap...but isn't it 3 ac3 frames/1 chunk then?

Originally posted by Chibi Jasmin
Isn't it 2 chunks and 3 chunks in a varying pattern? Well, anyways, that's what I wanted to know, so everything should be fine.

I got to this by looking at this thread: http://forum.doom9.org/showthread.php?s=&threadid=23504 and counting '00dc's between each '01wb' and that is varying between 2 and 3... :D

Originally posted by alexnoe
You've summerized correctly.

It will be hard to find out what happenes with the fracted frame at the beginning...I do not know how to determine whether a delay of <32ms is present or not.
You could try inserting more "half" frames to get an audible delay (or not).

BUT: If it is causing no delay, then the file would replay fine at the beginning, but would run off sync as soon as you seek (seeking in the audio stream of an AVI file is only based on "time / bitrate")

Hmm...why would it go off-sync, if it caused no delay (I didn't get that time/bitrate thing)? And I already thought about inserting more than one half-frame, but had no idea how to achieve that...any hints?

[alexnoe]

=> you confuse frames and frames!

One AC3 frame lasts 32ms, one video frame lasts 40 frames. => 3 AC3 frames last 96 ms, which is about 2,5 video frames. => of course you get 2/3/2/3...00dc chunks. But these are video frames, not AC3 frames :D

Seeking in an AVI files work like this for audio:

Lets say, you want to seek to the position "1 hour"
=> 448 kBit audio => you can calculate the byte position at which you have "1 hour"

If you have crap data at the beginning, which is not replayed, it would tell the wrong position

[Chibi Jasmin]

Originally posted by alexnoe
=> you confuse frames and frames!

One AC3 frame lasts 32ms, one video frame lasts 40 frames. => 3 AC3 frames last 96 ms, which is about 2,5 video frames. => of course you get 2/3/2/3...00dc chunks. But these are video frames, not AC3 frames :D

You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

[alexnoe]

Yes

[Chibi Jasmin]

Originally posted by alexnoe

Seeking in an AVI files work like this for audio:

Lets say, you want to seek to the position "1 hour"
=> 448 kBit audio => you can calculate the byte position at which you have "1 hour"

If you have crap data at the beginning, which is not replayed, it would tell the wrong position

But it would still be off for only the small value, the fracted frame would have caused? But you say it goes progressively out of sync? I somehow don't get it...sorry for my stupidity...

[alexnoe]

It doesn't go progressively out of sync.
Still assuming that crap data at the beginning is ignored if you start the replay.

It would start playing fine, but as soon as you seek, it would run out of sync (yes, only a very little bit), and would then keep that off-sync at a constant value, regardless of what you do later.

[Chibi Jasmin]

Originally posted by Chibi Jasmin
You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

Originally posted by alexnoe
Yes

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? :)

BTW: How could I insert more than one fracted frame at the beginning for testing? Any idea?

[Chibi Jasmin]

Originally posted by alexnoe
It doesn't go progressively out of sync.
Still assuming that crap data at the beginning is ignored if you start the replay.

It would start playing fine, but as soon as you seek, it would run out of sync (yes, only a very little bit), and would then keep that off-sync at a constant value, regardless of what you do later.

Hmm...does it go more out of sync than the length of one ac3-frame = 32 ms (the maximum delay a fracted frame, let's say 1 byte missing, could cause)? I am asking, because I didn't understand the calculation...

[alexnoe]

Hmm...does it go more out of sync than the length of one ac3-frameNo, probably not.
But if you don't care about 32ms, then there is no need to implement AC3 silence when encountering broken AC3 data...

[Chibi Jasmin]

Originally posted by alexnoe
No, probably not.
But if you don't care about 32ms, then there is no need to implement AC3 silence when encountering broken AC3 data...

Well, I do care :D In fact, I am actually hoping, that these fracted frames cause a delay...btw: why wouldn't it be out of sync from the beginning, but only when seeking?

But what I fear (that's why I always wanted silence padding in avimuxgui), is that the error accumulates, if you join multiple nandub files with corrupt frames...if everything fits, avimuxgui can join the split frames from one cd to another, if I got it right, and would only delete the first fracted one causing a delay < 32 ms, but if there's some more corrupt frames somewhere for whatever reason, the delay error, if there's no silence padding inserted accumulates more and more...

Hmm...I will see, if I can somehow insert multiple fracted frames at the beginning of a video to check, if it causes a delay...still no idea, how to do it, though...

[alexnoe]

Well, I do care In fact, I am actually hoping, that these fracted frames cause a delay...btw: why wouldn't it be out of sync from the beginning, but only when seeking?Maybe because I have written that I assume for these thoughts that broken data at the beginning of the replay is ignored? If it is not ignored, then it could indeed set a delay <32ms without side effect, but I won't do it!

[Chibi Jasmin]

Originally posted by alexnoe
Maybe because I have written that I assume for these thoughts that broken data at the beginning of the replay is ignored? If it is not ignored, then it could indeed set a delay <32ms without side effect, but I won't do it!

You got the question wrong, I guess....

Two things:

1. You said, if one fracted frame at the beginning caused no delay, it would go out of sync on seeking...my question is...why not instantly on playing?
2. I didn't want you to make AviMuxGUI capable of inserting fracted frames at the beginning to make delays <32 ms possible. Just discard the fracted first frame, if there is one (if begin > gran./2 better add 32 ms delay automatically), as you do now.... What I wanted is, that you insert a full 32 ms long silence frame, wherever you encounter a broken ac3 frame somewhere in the middle of the stream. Please!

[alexnoe]

You said, if one fracted frame at the beginning caused no delay, it would go out of sync on seeking...my question is...why not instantly on playing?I didn't get it wrong. Again: IF the player first ignores the broken beginning, then it will start in sync. IF = falls...
But when seeking, the calculation of the new position within the stream cannot take care of that beginning.

[Chibi Jasmin]

Originally posted by alexnoe
I didn't get it wrong. Again: IF the player first ignores the broken beginning, then it will start in sync. IF = falls...
But when seeking, the calculation of the new position within the stream cannot take care of that beginning.

Call me dumb, but then it should be the other way round?

It ignores the fracted frame, so it is slighty off-sync...you seek...it calculates the offset by total length of audio, taking the fraction at the beginning into account and then is in sync? :D

[alexnoe]

If off-sync before => maybe on-sync afterwards
If on-sync before => off-sync afterwards...

[Chibi Jasmin]

Originally posted by alexnoe
If off-sync before => maybe on-sync afterwards
If on-sync before => off-sync afterwards...

Okay...I'll just eat this!

Originally posted by Chibi Jasmin
You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

Originally posted by alexnoe
Yes

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? :)

I always got confused by these indexes at the end...how does this work? Let's say we have a 96ms/96ms 25 fps file. one 01wb is an audio chunk lasting 96 ms. one 00dc is one video frame lasting 40 ms, so we have this 2/3 pattern. The indexes say something about how the chunks are organised in the file? One chunk is always stored consecutively...for audio this is 3 frames = 96 ms...and then comes either 2 or 3 video frames that are also stored fully and not somehow fracted...then an audio chunk again...on playback audio and video is read and somehow synced to play correctly...so the index at the file is just indicating how things are stored in the file...the actual length of one video frame or one audio chunk is determined elsewhere and (frame rate, ac3framesize) and these values are used to calculate how the video and audio play together...these 01wb's and 00dc's in a varying pattern have nothing to do with video or audio frames being fracted or synced/not-synced! Is that correct? Probably a dumb explanation...can you shed some light into this?

BTW: How could I insert more than one fracted frame at the beginning for testing? Any idea?

---

take a break, if you don't feel like answering right away, anytime...but I am indeed thankful to you sharing your wisdom with me... ;)

[alexnoe]

At first: This is one chunk of an AVI file:
typedef struct
{
DWORD dwFourCC;
DWORD dwLength;
BYTE bData[dwLength];
}
The first 8 bytes are called chunk header

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? Both
The indexes say something about how the chunks are organised in the file? The index specifies Stream which a chunk belongs to (number and audio/video) the position and size of each chunk keyframe or deltaframe the order in which the chunks of one stream are played (which is *not* necessarily the order in which the chunks really occur in the file. Although storing them in a weird order does not make sense, except for copy-protecting a CD containing an AVI file, it would be allowed)A Video frame has to occupy one chunk. Fracting is against AVI specs.the actual length of one video frame or one audio chunk is determined elsewhere and (frame rate, ac3framesize)There are 2 framerate values within each AVI file. The first one is ignored by DirectShow (and sometimes broken when using M$ software!). The length of each chunk, measured in bytes, is found in the index, and of course in each chunk header.these 01wb's and 00dc's in a varying pattern have nothing to do with video or audio frames being fracted or synced/not-synced! Is that correct?correct.

[Chibi Jasmin]

Thanx for that easy explanation...! :) I searched a bit in the meantime, but didn't really get too much out of it...

Learned a lot today :D

[Chibi Jasmin]

@alexnoe:

It seems that ReClock Sound Renderer http://ogo.nerim.net/reclockfilter (there's also a thread in the general discussion forum about it) plays badly muxed ac3-avis from nandub (1fr/500ms) fine without choppiness, whereas DefaultDirectSound plays choppy...do you have any idea, why this might be so?

[alexnoe]

Maybe this tool is fiddling the chunks together to
complete AC3 frames before passing them other to any other filter.

[Chibi Jasmin]

Well, it does not pass on anything to any filter...that tool is an audio renderer itself and get's the decoded audio from the ac3-decoder...

[Macen]

I have downloaded AVI-Mux GUI 1.13. I read in the guide that default settings should be fine. And when I looked at the screenshot, audio interleave was at 75. But 75 what? Frames or kB? In the version of Avi-MUX GUI I've got, default audio interleave is at 250kB. What is the correct default setting? :)

[alexnoe]

The guide is old.... 250 KB is fine :D

[Macen]

Ok, thanks- Will try that. I tried 960ms preload and 96ms interleave before, but my friend had troubles with the file. He has got an Audigy 2 soundcard. It worked fine on my computer (Zoltrix Nightingale Pro 6).