DGMPGDec 1.4.0 Final!

[Doom9]

well.. this currently works only for AC3 (I've asked people to report back to me if they have DVDs with PCM or MP2 tracks.. I don't have such discs to test). I get the track ID from the DVD Decrypter info file. Let's say the user selects the first and second audio track, which have IDs 0x80 and 0x82 respectively. DGIndex turns that into T01 and T03. So, I store the relative ID difference before indexing, then go searching the output folder for T01 and T03 in the filename, and excluding DTS files that might interfere. I guess this could conflict if the source also has PCM and/or MP2 audio, so being able to limit which tracks I want would solve that problem as well.

[gte024h]

I think I found a bug in the "Decode AC3 Track to WAV" function in DGIndex 1.4.0. Sometimes the WAV file is about 2 seconds shorter than the video. Using DGIndex 1.3.0 with the same VOB produces a correct length WAV file. This has happened on 3 different DVD's so I think it's not a problem with the content.

I would post a sample VOB for you to examine, but if I cut a 20mb slice out and post it, the problem will hardly be detectable. For a 2 hour video, audio shrinkage of about 2 seconds is minor but it ruins dialog synchronization.

I understand why you don't want to implement audio decoding in DGIndex (simple tools that do thier job very well, other tools already do it well, etc.) but it is convenient to have AC3 automatically converted to WAV. Perhaps it would be easier to demux the audio track, and if the user selected AC3 to WAV, then have DGIndex run azid (with the appropriate command line flags) to convert the file. It would be as good as doing it manually with BeSweet, but fully automated for us lazy people ;-) Of course it would require that the user have a copy of Azid and that DGIndex knew where it was located.

[Guest]

I just tried it with 1.3.0 and 1.4.0 and the two wave files were identical.

If you are right, even a 20MB sample VOB ought to produce two files that are different in file length. So, please post a VOB and all the DGIndex settings.

[gte024h]

I just ran the demuxed AC3 through Azid and it complained of CRC errors in a couple of spots. I also notice in the DGIndex Info area it says "audio error" when processing the VOB. I suppose that the way audio errors are handled has changed in the most recent version of DGIndex.

If you would still like a sample, I can try to cut a part out of this VOB where the error is. Just let me know and I'll see if I can get a good sample (with errors) online for you.

[Guest]

Yes, I'm interested, because nothing should have changed. You can upload it to my FTP server and inform me of the file name here. Thank you for your trouble report.

[fmonroy]

I just ran the demuxed AC3 through Azid and it complained of CRC errors in a couple of spots. I also notice in the DGIndex Info area it says "audio error" when processing the VOB. I suppose that the way audio errors are handled has changed in the most recent version of DGIndex.

If you would still like a sample, I can try to cut a part out of this VOB where the error is. Just let me know and I'll see if I can get a good sample (with errors) online for you.

check if some scene has multi-angle, i got the same audio error with one of them;if yes just try to rip the correct angle.

hope it helps.

[Cyberia]

I have a feature request for the commandline if you wouldn't mind: allow the selection of multiple audio track IDs to be demuxed.
I tend to agree, this would be a Good Thing. We could eliminate the "Demux All" option and add a "All Tracks" option to the track selection sub-menu. This would give us "Demux" and "Decode" processing options and the track selection would be All, then Tracks 1-8 (allowing multiselect)

Hmmm, worth considering.

Perhaps it would be easier to demux the audio track, and if the user selected AC3 to WAV, then have DGIndex run azid (with the appropriate command line flags) to convert the file.
This was the original idea behind removing the Decoding stuff. Just push the audio directly into BeSweet (or azid since BeSweet will just send it into azid)

The only problem I see with that, is what about all the BeSweet options? We're not going to build a BeSweet GUI into DGIndex. Perhaps DGIndex could Demux and then launch BeSweet. Can the BeSweet GUI be launched with an input/output file already specified?

I'm not even sure this is worth re-addressing. Experienced users are going to use the AC3 directly, or use BeSweet if they need to convert it. The Decoding is there only for users who want an integrated solution, but it certainly is substandard for a 'production' environment.

[ScottZ]

Apologize for asking, but just to confirm... 140rc7 should be working with AviSynth 2.5.6b4?

Thanks

[Wilbert]

AviSynth v2.5.6b4 (and v2.5.6 final when it is ready) will work with all versions of dgdecode. AviSynth v2.5.7 will require dgdecode 1.4.0.

[Guest]

Regarding Doom9's feature request:

Obviously, if that is implemented for the CLI it would be implemented for the menus as well. I have multi track selection working for demuxing; it's not difficult. But decoding is a different matter, because the decoder files in the AC3 directory are implemented using a lot of global variables, meaning supporting multiple decodes is not possible without a big overhaul (which I'm not motivated to undertake).

So, would it still be worthwhile making this change if the decoding has to enforce a single track selection while demuxing has multiple track selection support?

[Doom9]

So, would it still be worthwhile making this change if the decoding has to enforce a single track selection while demuxing has multiple track selection support?Imho yes since the decoding feature is less important than the demuxing feature.. the former is much less used than the latter.

I think pretty much all the programs that automate DGIndex would profit from this change (well, assuming they offer multiple track selection obviously).

[Guest]

@Doom9

OK. Please see the new 1.4.1 beta thread. Thank you for your suggestion.