Does anyone use "Process WAV"?

[Guest]

I'm considering removing some of the legacy audio stuff from DGIndex, but before doing that I thought I'd better poll the users. Let's start with the "Process WAV" functionality. Does anybody actually use this feature?

FYI, it's easily performed in (for example) BeSweetGUI, azid, etc.

[madoka]

I've never used it. I always demux the AC3 track and process it separately using azid. I guess there's no good reason why I do this, but old habits die hard.

So I vote for removing the feature. :sly:

[iNFO-DVD]

No problems here, as long as I can still demux the audio, AC3 & MPA.

[manono]

Hi-

Does anybody actually use this feature?

I use it for those rare instances that the DVD has LPCM audio. Otherwise, for AC3 audio, I'm like the rest and do any audio conversions necessary outside of DGIndex.

[fccHandler]

Honestly, I never even noticed it before today.

[iNFO-DVD]

Just a quick thought, I presume obviously the demuxing with stay, is there anything you can do if the audio is LPCM (demux/extract) so it can be further processed by a 3rd party app as in mpa & ac3?

[geoffman]

Yeah, like manono I use it occasionally for much the same reasons.

[Guest]

I use it for those rare instances that the DVD has LPCM audio. Why is it needed in that case? Are you conflating this with "Decode to WAV", which I have not proposed to eliminate?

[Guest]

Just a quick thought, I presume obviously the demuxing will stay, is there anything you can do if the audio is LPCM (demux/extract) so it can be further processed by a 3rd party app as in mpa & ac3? Wouldn't "Decode to WAV" be adequate?

[Wilbert]

@neuron2,

Not every lpcm is supported. Once i posted a link with different kind of samples:

http://forum.doom9.org/showthread.php?p=630154#post630154
second download link: http://www.videohelp.com/~jsoto/AudioTests/
contents: http://www.videohelp.com/~jsoto/AudioTests/infoAudioDVD.txt

I hope you can look at it :)

[Cyberia]

Both "Process WAV" and "Decode to WAV" need to be removed. Yes, we know about the LPCM issue.

Wilbert you and others are talking about the "Decode to WAV" option not "Process WAV"

[ron spencer]

why remove process/decode to WAV? it is handy

[manono]

Doh! Decode To WAV is what I thought you meant. I know, if you had meant that, you would have said it. I don't even know what Process WAV does, have never used it, so I guess I don't need it.

I had to look up "conflating", too. I don't think I'm conflating, just confusing. :)

[Wilbert]

So, what does "Process WAV" do?

[Guest]

@manono

I thought it would be insulting to suggest that you were confused.

@ron spencer

I'm a strong believer in proper partitioning of functionality. There are a lot of "handy" things that could be thrown in, but do they really belong there? Also, there are better solutions available nowadays. And from a practical standpoint, I don't want to have to maintain and document this stuff. Maybe Cyberia will give you his take on it, too.

[Guest]

So, what does "Process WAV" do? It lets you apply sample rate conversion (SRC) (48 -> 44.1), normalization, and delay correction to existing WAV files. But the SRC is not the best nowadays, the normalization is limited to attenuation, and these things can be much better performed with modern audio applications.

[unskinnyboy]

I don't use the feature either and I also agree that this functionality is better left to the constantly updated audio apps. :)

[guada 2]

For my part, i always demux the AC3.

@Neuron2

Would you have other projects for DGindex?

[Cyberia]

Maybe Cyberia will give you his take on it, too.

Always glad to give people a piece of my mind ;)

Several audio functions were added to DVD2AVI back in it's original incarnation. They were added because there was a real need for these functions and no alternative software existed then.

Times have changed.

There are several audio applications available (BeSweet comes to mind first and foremost) that can perform ALL of the audio functions in DGIndex and do them better and faster. Plus they provide many other options not in DGIndex. Additionally, these other programs are in active development, whereas the 'Decoding' functions in DGIndex have not been updated in years.

The Demux functionality of DGIndex will not be affected by this. AGAIN: Demux will remain and continue to be improved.

The following functions are strongly being considered for removal:

Process WAV
Decode to WAV
Dolby Digital Decode (and sub functions)
48 -> 44.1Khz
Normalization

[Guest]

Would you have other projects for DGindex? Please see the sticky thread called "DGMPGDec Development List" for pending work.

[Guest]

The following functions are strongly being considered for removal:

Process WAV
Decode to WAV
Dolby Digital Decode (and sub functions)
48 -> 44.1Khz
Normalization That's right. So as they say at weddings, if you have any objections come forward, or forever hold your piece (or is that "peace"?).

[iNFO-DVD]

Originally Posted by iNFO-DVD
Just a quick thought, I presume obviously the demuxing will stay, is there anything you can do if the audio is LPCM (demux/extract) so it can be further processed by a 3rd party app as in mpa & ac3?

Originally Posted by neuron2
Wouldn't "Decode to WAV" be adequate?
What I meant was this:

At the moment I'm saying.... 'Demux All Tracks' (via 3rd party proggy), It's just the job, don't have to worry about anything and when it's finished I can take a look at what's there, AC3, DTS or MPA. I don't need to know anything about the audio beforehand as DGIndex will tell me all I need by it's audio files dropped.

Well, if the audio track is an LPCM I'm stumpt as nothing will happen after a 'demux all tracks' as I'm sure it would need a, as you said, 'Decode to WAV', now if I had a option to allow the LPCM get treated as the other audio types do when a 'demux' request is passed would be just awesome. By treated I mean it comes out so aware of it and can do some further processing on it.

Does that make sense?

[Guest]

Does that make sense? Yes. I will not leave you without a means to extract LPCM audio. Wilbert would never let me get away with that. :)

[guada 2]

" Please see the sticky thread called "DGMPGDec Development List" for pending work "(Neuron2).

I Am Not Necessarily Aware Of the Operations in Progress, Since I Work.
I Think That You Can Understand That.

However, thank you for the information.

[Guest]

I Think That You Can Understand That. I have no idea what you are talking about. I tried to answer your question in good faith.

[iNFO-DVD]

I will not leave you without a means to extract LPCM audio.

So does that mean when I 'demux all tracks' it will do something with the LPCM?

[unskinnyboy]

That's right. So as they say at weddings, if you have any objections come forward, or forever hold your piece (or is that "peace"?).
To be precise, it is: Speak now or forever hold your peace. :)

[Wilbert]

So does that mean when I 'demux all tracks' it will do something with the LPCM?
It means be patient, he will work on it!

[Guest]

So does that mean when I 'demux all tracks' it will do something with the LPCM? Yes, exactly. Most likely it will create a WAV file. We could create raw audio, but would anyone want that?

[Cyberia]

Yes, exactly. Most likely it will create a WAV file. We could create raw audio, but would anyone want that?
No, a WAV will work.

Is PCM -> WAV anagalous to MPEG-4 -> AVI? In other words, is the WAV format a container format for PCM audio?

[iNFO-DVD]

Yes, exactly. Most likely it will create a WAV fileCool, look forward to future versions.

[Guest]

Is PCM -> WAV anagalous to MPEG-4 -> AVI? In other words, is the WAV format a container format for PCM audio? Yes, exactly.

[geoffman]

Why is it needed in that case? Are you conflating this with "Decode to WAV", which I have not proposed to eliminate?

Oops, I misread it too, decode to wave is what I use sometimes..... :o

[Guest]

Good news for Wilbert...

I have 48KHz/96KHz, 16-bit/24-bit, stereo/mono LPCMs working correctly. They'll be supported in 1.4.0 final.

I can't find any specs or code examples for the 20-bit parsing.

[mg262]

I'm pretty new to this, but FWIW I've never used that feature either.I'm a strong believer in proper partitioning of functionality. Hear, hear! Especially with CLI support!

[Wilbert]

Great thanks!

I wanted to point you to a thread in the dev section, but i see you already responded in that thread :)

It's perhaps nice to add audio info (like no of channels, bit-depth, samplerate, etc ...) to the demuxed filename?

[ron spencer]

ok just to be straight here...if you have LPCM audio it will still demux....but anything else (including ac-3) you have to do yourself later (via. belight etc)

[unskinnyboy]

ok just to be straight here...if you have LPCM audio it will still demux....but anything else (including ac-3) you have to do yourself later (via. belight etc)
No. Please read what Cyberia emphasized in post #19. The Demux functionality is untouched - you can still demux AC3, MP3, DTS, AAC same like you used to before.

[ron spencer]

My post was poor....I meant to say that there will be no conversion from ac-3 to WAV, etc. sorry

[Guest]

My post was poor....I meant to say that there will be no conversion from ac-3 to WAV, etc. sorry Correct.

[ron spencer]

this is fine by me really....the demux is all that is really needed as belight, etc do a fine job

[WarpEnterprises]

I will miss the decode to WAV functionality, as there AFAIK is no AviSynth plugin to load AC3 and do a controllable downmix (dynamic range compression).
Although the plugins from Nic/A_afra seem to partially do the job.
Maybe I overlooked some possibilities?

[Guest]

I will miss the decode to WAV functionality, as there AFAIK is no AviSynth plugin to load AC3 and do a controllable downmix (dynamic range compression).
Although the plugins from Nic/A_afra seem to partially do the job.
Maybe I overlooked some possibilities? Is it just that you don't like having to do an extra step in a different application? Or is there something else?

Let's put our efforts into getting the AC3 source filter to do what we need. Can you specify what is missing from Nic's AC3 filter?

[shawbros]

I use "Decode to WAV" all the time! It's one of the most convenient features and a great loss.

[Guest]

I use "Decode to WAV" all the time! It's one of the most convenient features and a great loss. What does it do for you that can't be done using AC3Source() or NicAC3Source()?

If you want the feature retained, you'll have to justify it.

[Cyberia]

I will miss the decode to WAV functionality, as there AFAIK is no AviSynth plugin to load AC3 and do a controllable downmix (dynamic range compression).
Although the plugins from Nic/A_afra seem to partially do the job.
Maybe I overlooked some possibilities?

I don't understand. DGIndex doesn't currently provide any sort of Downmix/DRC within AviSynth. And removing the Deocding stuff doesn't prevent you from using BeSweet to generate a WAV from the AC3.

It seems like you are going to miss a feature that doesn't exist.

[squid_80]

What if instead of the decode to wav option (which outputs pcm) there was an option to add a wav header to the demuxed ac3 file, the same as projectX has? Then if ac3acm is installed the wav file can be loaded easily by avisynth, virtualdub etc.

[Cyberia]

Can someone enlighten me on why a WAV file is needed at all?

If you are authoring a DVD or encoding an AVI, you can just mux in the original AC3 audio and be done.

If you want to create a MP3 (or MPA) you can do that directly with BeSweet without creating the WAV file. Direct AC3 -> MP3(A) conversions have been possible for a while now.

Of course BeSweet can also create a Downmixed/Normailized/DRCd WAV file also.

What are people doing with WAV files that is any harder if we remove the Decode functionality?

[squid_80]

Well, things won't be harder for me if decode functionality is removed. I was just proposing another option for the people that say they will miss it. Here are the reasons for my proposal:

a) Avisynth's wavsource() command will load ac3 data if it has a wav header and ac3acm is installed. No worrying about plugins to get ac3source() etc.
b) Regular virtualdub (not mod) can only use wav files for adding audio. Sticking a wav header on the ac3 makes it possible (again using ac3acm) to mux the ac3 data directly or transcode to something else within virtualdub.

[Guest]

I don't understand. DGIndex doesn't currently provide any sort of Downmix/DRC within AviSynth. Yes, but DGIndex provided those things and the OP wants to be able to get the same functions through Avisynth and not have to resort to another application, such as BeSweet. I'm happy to help in enhancing an AC3Source() filter in that regard. Let's hear what things are needed to fully obsolete the decoding stuff in DGIndex.

@squid_80

I'd consider the WAV wrapper for 1.5.0.

[shawbros]

What does it do for you that can't be done using AC3Source() or NicAC3Source()?

If you want the feature retained, you'll have to justify it.It is an extremely fast & convenient 1-step way of obtaining a WAV for editing in an audio app without the extra steps of going thru AC3Source (or other) and worrying about delay values. I think it worked great as it was and doesn't require any maintenance. Couldn't you just leave it there or are you concerned that it's getting cluttered with too many options? I think as long as other functions are not being compromised more features only enhances your app but loosing features is a pity. Either way I really appreciate your work, thanks for the reply!

[Cyberia]

a) Avisynth's wavsource() command will load ac3 data if it has a wav header and ac3acm is installed. No worrying about plugins to get ac3source() etc.
Why do people want to send audio into AviSynth? (I'm not being insolent, just trying to understand what people are doing)


b) Regular virtualdub (not mod) can only use wav files for adding audio. Sticking a wav header on the ac3 makes it possible (again using ac3acm) to mux the ac3 data directly or transcode to something else within virtualdub.OK that I understand. However, I use the combination AVIMux_GUI+AC3Filter rather than VDub+ac3acm, and no wav wrapping is necessary.

[iNFO-DVD]

That's right. So as they say at weddings, if you have any objections come forward, or forever hold your pieceWhy didn't anyone raise any issues/concerns about the audio when 'neuron2' made this comment? He did say/ask before he removed it.

One thing that was touched upon though was the faking of headers for VirtualDub... I'd love to see a little program of some some that could fake the headers of all mp3/ac3 files so I could use VD instead of VDM, anyway, that's probably for another thread.

[mg262]

Why do people want to send audio into AviSynth? (I'm not being insolent, just trying to understand what people are doing)Speaking just for myself, I mainly pull audio into Avisynth because:

- I'm dubbing DVDs with captured audio and I need to trim the audio to match the video length. (Trim(0,0) and the like.)

- I can save .AVIs with sound in one step (typically for testing rather than final production).

- Again when dubbing or using VHS source I can use AudioGraph to check a/v sync.

I wouldn't perform rate change, denoising, etc. of audio in AVS because IMO there are much higher quality tools out there for this.

(None of that requires the feature being discussed.).

[squid_80]

Why do people want to send audio into AviSynth? (I'm not being insolent, just trying to understand what people are doing)

The only time I ever do it is as a quick and dirty way to join different clips together. Not a very regular occurrence but it does happen now and then. Really I only mentioned it because it seems to be what other people want to do and I thought it might be a solution.

OK that I understand. However, I use the combination AVIMux_GUI+AC3Filter rather than VDub+ac3acm, and no wav wrapping is necessary.
Using vdub (with ac3 in a wav) I can trim out commercials and then transcode the video and audio together. Much easier than using mpeg2schnitt to cut the commercials, then besweet to transcode ac3->mp3, then vdub to transcode m2v->xvid then mux audio+video for final avi. If I want to keep the original ac3 rather than using mp3, I just set audio to direct stream copy. Still saves me using mpeg2schnitt and creating more files.

[shawbros]

Why didn't anyone raise any issues/concerns about the audio when 'neuron2' made this comment? He did say/ask before he removed it.That all happened in a matter of days. I don't have time to watch the forums everyday!
Why do people want to send audio into AviSynth? (I'm not being insolent, just trying to understand what people are doing)It keeps good synch when editing.

[Doom9]

Using vdub (with ac3 in a wav) I can trim out commercials and then transcode the video and audio together. Much easier than using mpeg2schnitt to cut the commercials, then besweet to transcode ac3->mp3, then vdub to transcode m2v->xvid then mux audio+video for final avi. If I want to keep the original ac3 rather than using mp3, I just set audio to direct stream copy. Still saves me using mpeg2schnitt and creating more files.And how does an application that is completely unaware of AC3 make the cuts properly? It would have to cut the AC3 stream so that AC3 frames are left untouched.. if that happens, it's basically sheer luck or uncompressed WAV files just happen to be treated the same way.

Either way, you can also use VDubMod which is AC3 aware.. and DVD2AVI never write an AC3 with WAV header.. you always had to do that on your own.. so you'd end up using the demux functionality, not the decoding facilities that have now been removed.

I'm one of the many that never used audio processing.. d2a/dgindex is excellent for finding the delay and I have BeSweet to turn the AC3 into whatever I want it to become.. and it offers way superior decoding facilities and a lot of other features. I guess it could be one program more but with all the benefits I get by using it (most notably direct transcoding (speed and filesize)) I'm not at all unhappy with that and I fully support the decision to remove fonctionality that is rarely used and inferior to a widely used tool. And from personal experience, just because the feature doesn't change doesn't mean the one maintaining the code won't have to spend extra time on the parts that seem unchanged in the end.

[squid_80]

I fear this is starting to get off-topic...

And how does an application that is completely unaware of AC3 make the cuts properly? It would have to cut the AC3 stream so that AC3 frames are left untouched.. if that happens, it's basically sheer luck or uncompressed WAV files just happen to be treated the same way.

I don't know the specifics, but I know it works. Maybe vdub has been improved, maybe ac3acm helps it know where to cut... All I know is it works correctly, there's nothing wrong with the resulting ac3 stream.
Either way, you can also use VDubMod which is AC3 aware.. and DVD2AVI never write an AC3 with WAV header.. you always had to do that on your own.. so you'd end up using the demux functionality, not the decoding facilities that have now been removed.
I use projectx to demux, giving me the ac3 in a wav. But I still have to run dgindex on the video to get the d2v. If dgindex gets improved so it can parse bad transport streams and demux the audio, I could drop the projectx step - but then I'd need to use mpeg2schnitt or vdubmod to cut commercials. The reason I prefer original vdub over vdubmod is because I use the x64 version and I like the ~10% speed increase.
I'm not complaining about losing the decode feature at all, I never used it - just thinking ahead a bit.

[Zep]

I fear this is starting to get off-topic...
I use projectx to demux, giving me the ac3 in a wav. But I still have to run dgindex on the video to get the d2v. If dgindex gets improved so it can parse bad transport streams and demux the audio, I could drop the projectx step
exactly! Right now I'm stuck using projectx which is SLOW cause it is java
then the m2v and ac3 from that I now have to Besweet the ac3 to wav and then
DGindex (end up in in DGindex no matter what anyway so...) on the m2v so it would
be great if DGindex could fix bad streams like projectX on pass1 then pass2 for
a d2v and wav with the d2v pointing to the wav and ready to go so i can use VDub
to edit out commerials with ease and good sync. Cutting uncompresed WAV keeps
sync much better than cutting ac3 or mp3.

Now i could edit in projectx (or HDTVtompeg or whatever) but it/they only
cut at the GOP level when working directly on the .ts file and editing on
the ac3 the sync goes wacko often enough that you can never trust it fully.
I never get sync problem when editing uncompressed wavs.

now projectx can make a d2v but DDGDecode.dll can't read it or any of the
mpegtosource versions i tried.

projectX can also demux to wav some stuff but again editing is done at the
GOP level and that is not good enough.

The thing that many here seem to forget is that a lot of us use this on
TV shows and have to edit where as the original was called DVDtoAVI
and you never really edit a movie and just rip straight up.

HDTV streams encoding has really taken off and the rez is so much higher
than standard DVD's it makes standard DVD's look like crappy low rez VCD

Anyway, my point is keep your sights on the future of DGindex and if
you do plan to add projectX stream fixing then I say you should keep
ac3 to wav feature. If you do NOT plan to add stream fix code then
might as well dump all ac3 to wav options.

IMHO of course :)

[WarpEnterprises]

@neuron:
I use DGIndex only together with mpeg2source in AviSynth, so indeed it would be clean and straightforward to upgrade an ac3source and process as much as possible directly in AviSynth.
MarcFDs AC3Source is without source and some hidden default downmix -> not future-proof
NicAC3Source seems a much better starting point.
It should support:
- sample accurate seeking (even when accessing non-linear)
- adjustable downmix (outputting the number of channels you like thus supporting AviSynth's multichannel facilities)
- no need for separate indexing of the AC3
- adjustable dynamic range compression (although this could or maybe even should be a separate filter).

[Cyberia]

Please keep things On Topic.

We are drifting to ac3 filters, which don't have anything to do with DGIndex.

[GaveUp]

exactly! Right now I'm stuck using projectx which is SLOW cause it is java
then the m2v and ac3 from that I now have to Besweet the ac3 to wav and then
DGindex (end up in in DGindex no matter what anyway so...) on the m2v so it would
be great if DGindex could fix bad streams like projectX on pass1 then pass2 for
a d2v and wav with the d2v pointing to the wav and ready to go so i can use VDub
to edit out commerials with ease and good sync. Cutting uncompresed WAV keeps
sync much better than cutting ac3 or mp3.

If you are using ProjectX you can eliminate the need for DGIndex. PX will create old-style d2v files that work ok. Also, when cutting an ac3 directly, if the program doing the cutting behaves correctly, you will only end up with a +/- 16ms desync from the original. In other words, imperceptible for 99.999% of the people.


Now i could edit in projectx (or HDTVtompeg or whatever) but it/they only
cut at the GOP level when working directly on the .ts file and editing on
the ac3 the sync goes wacko often enough that you can never trust it fully.
I never get sync problem when editing uncompressed wavs.

now projectx can make a d2v but DDGDecode.dll can't read it or any of the
mpegtosource versions i tried.

Try MPEG2DEC3, which can be grabbed here (http://www.avisynth.org/warpenterprises/). It works fine.


projectX can also demux to wav some stuff but again editing is done at the
GOP level and that is not good enough.

If you have PX spitting out a WAV use WAVSource to bring it into AVISynth and AudioDub to combine it with the video again.


The thing that many here seem to forget is that a lot of us use this on
TV shows and have to edit where as the original was called DVDtoAVI
and you never really edit a movie and just rip straight up.

Ironically this is where I think the Proccess and Decode to WAV features are not needed. Because of the error prone nature of the source and the fact it is nearly impossible to ensure sync prior to doing a full encode in anywhere near a sane amount of time (I encode to 1280x720p so even doing samples takes a quite a while) I prefer to seperate things into as many steps as possible. That way if there is a problem I can back track just far enough to fix the problem and not have to do more work than needed. If you did audio work in DGIndex you would have to run that step over again and then you are effectively starting over.


Anyway, my point is keep your sights on the future of DGindex and if
you do plan to add projectX stream fixing then I say you should keep
ac3 to wav feature. If you do NOT plan to add stream fix code then
might as well dump all ac3 to wav options.

IMHO of course :)

Sound advice, if you ask me. Being that I primarily do HDTV encoding, also, I would love nothing more than to see DGIndex get some TS error handling options. That is no easy task, though. I've even made futile attempts at adding such things myself and acheived nothing more than a burning mass of crashes. I can't help but wonder if removing these features is in preparation of adding TS error handling code. It would definatly clean up the code a little bit, and any little bit counts when you're working with code like DVD2AVI/DGIndex. Lets face it, the code is an abomination (no offence towards neuron2, he inherited the abomination).

So in that respect I have no problem with the features disappearing. I'd also have no problem is all the Save to AVI code went missing too. In all the years I've used DVD2AVI/DGIndex I've never touched those features.

Nothing is ever simple, though, and I am torn about losing Decode to WAV. When I am using a DVD source and not keeping the AC3 this feature is just unbelievably convenient. Granted, there are other tools that do the job, but when I'm doing a DVD source I typically just want a quick, down and dirty encode and don't want to mess with a bunch of other apps. After all, if I was after a high quality encode then I'd keep the AC3 audio.

In the ideal world, I'd like to see Decode to WAV stay in a basic capacity (that wouldn't need to be maintained). No need to support resampling or any of that. Just a basic AC3 to WAV option. It would let us who find the feature to be extremely convenient in some circumstances to keep using it and for those that don't they'd not be losing anything either. Now if it's a choice between cleaning up the code to make adding other features easier and keeping this functionality I say do away with it, fast, quick, and in a hurry, but if it isn't hurting anything right now I can't see what reason there is to remove it.

[Xesdeeni]

I've had several novices ask about converting a DVD soundtrack to a CD. I've pointed them at DGIndex to convert the AC3 from the VOB to WAV (with 48->44.1 conversion) and then their favorite burning software to burn the WAV.

If DGIndex removes the feature, what is the easiest way (i.e. fewest steps) for me to tell them?

Xesdeeni

[Guest]

OK, I'll probably restore the Decode to WAV and hide it in a "Legacy Audio" pulldown. All other changes will remain, i.e., enhanced LPCM and treating it as demuxing.

[Cyberia]

I've had several novices ask about converting a DVD soundtrack to a CD. I've pointed them at DGIndex to convert the AC3 from the VOB to WAV (with 48->44.1 conversion) and then their favorite burning software to burn the WAV.

If DGIndex removes the feature, what is the easiest way (i.e. fewest steps) for me to tell them?

Xesdeeni

BeSweet. BeSweet can open vobs, and decode/encode the audio directly.

Decode to WAV isn't necessary.

EDIT: I just double checked this, and yes, BeSweet can do direct VOB->MP3 transcoding. (or WAV or any other format)

[Xesdeeni]

BeSweet. BeSweet can open vobs, and decode/encode the audio directly.

Decode to WAV isn't necessary.

EDIT: I just double checked this, and yes, BeSweet can do direct VOB->MP3 transcoding. (or WAV or any other format)I didn't realize BeSweet would open VOBs...Thanks! It's still a bit more involved, since I either have to teach them CLI (well, the be fair, _I_ have to learn BeSweet's CLI too) or they also have to get BeSweetGUI. But if DGIndex doesn't have the feature, that'll do.

Thanks again.

Xesdeeni

[Cyberia]

No prob.

I used BeSweetGUI. And BTW, I did have to download an additional dll from dsguru.doom9.org. Goto the Plugins page, it's the dll that allows VOB access.

I have NO IDEA if that dll is included in one of the package downloads.

[Xesdeeni]

Sorry, OT, but I had a great deal of problem with BeSweet last night. I did find the DLL for reading a VOB, although that wasn't what I was trying last night. I could get things converted to WAV (in this case from an AVI), but I couldn't convert to anything without an error. I was creating a DVD from an AVI with VBR MP3, so I needed to go to MP2 or AC3. Neither worked. I got an error 47 for MP2 and a error 74 for AC3. I normally use the BeSweetGUI, but I got the same error when I tried the command line (after I figured out that you must have spaces around the arguments in parentheses).

Xesdeeni

[Xesdeeni]

BTW, Don: http://www.avsforum.com/avs-vb/showthread.php?p=5855986&&#post5855986

:)

Xesdeeni

[Guest]

BTW, Don: http://www.avsforum.com/avs-vb/showthread.php?p=5855986&&#post5855986 Thanks for the plug. Maybe you should have mentioned that they need RC4 for the decode to WAV support until I restore it.

[Gurm]

I'm considering removing some of the legacy audio stuff from DGIndex, but before doing that I thought I'd better poll the users. Let's start with the "Process WAV" functionality. Does anybody actually use this feature?

FYI, it's easily performed in (for example) BeSweetGUI, azid, etc.

I don't, personally - but I've seen a "how-to" guide or two that rely on it. 'Course they're old, and half the time refer not to DGIndex but... uh... to what it was called before, anyway. :)

[kikounet]

If I can just give my opinion, I love and still use DVD2AVI to downsample (48 > 44.1) DVD ac3 to WAV bexause : The audio quality is simply the best! And it's done at the same time time as the *d2v (no other manipulation, can use the same start and end point, no mis-synching...)
Also, the Normalisation is very good, no clipping as in BeSweet (all the OTA, PreGain, PostGain and so on are very confusing and the quality...)

So thank you very much Neuron2 to have kept the Decode AC3 To WAV function! :thanks:

[Zep]

If you are using ProjectX you can eliminate the need for DGIndex. PX will create old-style d2v files that work ok. Also, when cutting an ac3 directly, if the program doing the cutting behaves correctly, you will only end up with a +/- 16ms desync from the original. In other words, imperceptible for 99.999% of the people.

I repeat. px only cuts at the GOP level which like i said is not good enough.
(not even close)

"if the program doing the cutting behaves correctly" grrr... LOL
i already said px does not behave correctly 100% of time. No
program I have tried does when cutting on AC3. This is why it is better
to do a straight full pass to wav and edit on the wav

16ms is WAY too much and with 6+ edits an hour it could get a lot worse

i mentioned in my last post projectX can make d2v files. I do not want to
use OLD style d2v.They do not work with DGIndex which is what i use and
like the best because it does more and does it better. DGIndex is what the
thread is about after all.

Try MPEG2DEC3, which can be grabbed here (http://www.avisynth.org/warpenterprises/). It works fine.

No it doesn't. it barfs on most .ts i feed it and it doesn't seek correctly.


If you have PX spitting out a WAV use WAVSource to bring it into AVISynth and AudioDub to combine it with the video again.

no i do not. px only cuts at the GOP level and like i said
that is not good enough. Also px only spits out WAV from mpeg
layer 1 and 2 unless a new version within the last month does AC3 also
which all my HDTV stream are so no I can't get wav from px


Ironically this is where I think the Proccess and Decode to WAV features are not needed. Because of the error prone nature of the source and the fact it is nearly impossible to ensure sync prior to doing a full encode in anywhere near a sane amount of time (I encode to 1280x720p so even doing samples takes a quite a while) I prefer to seperate things into as many steps as possible. That way if there is a problem I can back track just far enough to fix the problem and not have to do more work than needed. If you did audio work in DGIndex you would have to run that step over again and then you are effectively starting over.

i disagree. The more steps the more things that can go wrong.
More apps means you run into more bugs and more ways each app
THINKS it is doing the right thing. It would be best if DGindex
fixed the streams and demuxed then made the d2v all using the
same DG method and DG checks and balances for sync etc...

Furthermore, computers are supposed to make things easier not
harder and more complicated. I should not have to use a dozen apps
and jump through all these hoops just to edit and encode a tv show
in sync. :)

BTW - which is WHY i like the AC3 to WAV feature. I do not need to use
px if i get no drops in the stream I just run it through DGindex straight
up and use AC3 to WAV and and I can go right to VDub and edit on
the wav and it never messes up sync. (unlike editing on an AC3 which can
be a roll of the dice )

[GaveUp]

Well thanks to a computer crash my initial reply is lost, but I'll just sum up the main points. AC3 cutting done properly will yield a maximum of 16ms desync. This would not be compounded throughout the stream and multiple cuts. If you don't believe me try cutting a good stream with vdubmod, px, or ac3 cutter. Just because cutting is done at a GOP level does not mean the ac3 frames line up with those GOPs perfectly.

Also if you have problems with a program let the author's know. Don't just say it doesn't work. If you give constructive feedback things can actually get fixed. The vast majority of the people here are doing this as a hobby for no profit. No one can do everything so it's up to the other users to help the developers where they can. Saying it just doesn't work does not help.

Finally, we obviously differ on our views of what features should be in what program. I have my reasons coming from my experiences and you have yours. I've got no problems discussing this matter further, but lets do it in a more appropriate place as it would be way offtopic for this thread.

[Guest]

I don't mind you continuing the discussion here. I think it raises some useful information for me to consider for future versions.

[GaveUp]

I don't mind you continuing the discussion here. I think it raises some useful information for me to consider for future versions.

Ok, fair enough. In that case I'll expand a little on my previous post or rather retype a little more of what I lost. I guess when I look at the design of a program I think of it in terms of "Ok this thing is meant for this purpose and my goal is to make it do this very well." That's the first and foremost goal. In the case of DGIndex, I think that it does many things very well with it's main purpose being to index the source and serve it elsewhere. Obviously, though, there is room for improvement, especially in the area of dealing with digital captures. Being that this is the best place to add such functionality I think it deserves to be added in.

With the audio processing, issue though, it seems beyond the scope of what DGIndex needs to do. DGIndex, to me, is like a translator. It transforms information into a state other programs can handle. Other programs can handle AC3 or whatever other source audio you might encounter, and they do it better than DGIndex probably ever would. Of course, by that definition, then the Decode to WAV function would be a bloat feature too, but I have reasoning for thinking this functionality should remain. It's not needed, no, but it does give the option to users to use one program if they like. Decode to WAV allows for that basic functionality. Great. If you want something more in depth, such as resampling then it's probably best to go elsewhere. Why? Well, two reasons. The first is that, as mentioned above it would produce a better end product, and presumably if you are doing that much work to a source quality is a high priority. The second, is that it places a huge burden on the developer to add this functionality in and maintain it, as you've said whereas just having the basic functionality of decode to wav is a done deal once that bit of code is debugged.

Another reason for the functionality seperation, at least in the more advanced scenarios is that it allows for a finer control over the output. It is much easier to tweak options with specialized tools. It also makes it easier for a user to customize a process to their needs. With digital recordings processing them is still relativiely in its infancy. Many tools do not exist, or exist only in buggy or proof of concept states. I think once the tools mature a little more we'll see a much more easier process to handle the recordings show up. Maybe an application similar to dvd2svcd or some such that gives you one place to goto to set all your options, but at the same time utilizes seperate tools making it much easier to debug a problem (for user and developer) if something goes awry.

I guess my ideal scenario, and I apologize to the developers if I make you guys feel that I'm overstepping my bounds is this. Have a tool like DGIndex that does indexing, demuxing, and error control very well. Add in a few basic other features such as the Decode to WAV, Cropping, and maybe some basic resizing abilities. Then have tools specialized for handling the audio further. Besweet is a great option for this as it's already very complete. I guess on this front the only thing I really see missing is a high quality AC3 encoder. Besweet does a decent job, but just doesn't compete with commercial options. Now for beyond basic level processing of video have another application for this. AVISynth and VirtualDub are both excellent for this. This is what they do and they do it well. No need to reinvent the wheel. Obviously there may be more programs needed for say subtitling or whatnot, but you get the jist of my thinking, I hope.

Now it goes almost without saying that all these tools can quickly make a process extremely complicated. Obviously, the goal of these tools is to make the process simpler. So I think it would be called for to have an application that combines all these tools seemlessly. The good news is that just about all the needed applications work from a command line making writing an application to bring them together much easier.

I guess my one question is, how does the average end user really see things? I don't mean to tout myself as some God of programming but I've done enough that my perspective on programs is entirely different than the average person.

Some questions I'd have:

1) What about this sort of seperated, or stepped, process with multiple tools and one that combines them is good or bad? To me it seems like the perfect situation for everyone concerned and makes such a distributed coding effort as the internet allows for possible.

2) What are the benefits of an all in one app? It seems like with this approach the first thing to suffer is quality, and if that is the case then does not the entire point of digital capturing become null and void? If I wasn't concerned about quality I could have saved myself the large chunks of money I've invested in the needed equipment and just continued to use a $10 analogue card.

3) Where do you guys think the digital capturing process lacks? I'd assume an almost universal response would be dealing with error correction, but what else?

And last, but not least, something that has somewhat puzzled me.
4) Why was it chosen to use DVD2AVI as a base of code and continue with it over starting over. I've said before, and maybe I'm wrong, but the DVD2AVI codebase is rather ugly and give that you seem to have a God-like understanding of how the indexing processes work it seems like it might be benefiicial to start relatively clean. Take the salvagable code from DGIndex and start anew.

[Guest]

Thank you for taking the time to so clearly express your views. I'll respond to your questions posed at the end.


1) What about this sort of separated, or stepped, process with multiple tools and one that combines them is good or bad? To me it seems like the perfect situation for everyone concerned and makes such a distributed coding effort as the internet allows for possible. Yes, the "software tools" approach has a long and illustrious history, and its benefits are easy to see. It carries a danger, however, of separating things that perhaps shouldn't be separated. For example, in an MPEG2 transport stream, there are PTS timestamps that clearly and unambiguously sync the video to the audio. If you demux the audio and video to elementary streams for handling by separate tools, you lose that important information. I suppose you'll argue that after error correction and offsetting, the two stream rates perfectly define the sync, but it is not always so, because it relies upon clocks running very close to their specified values, and we've often seen cases where that requirement is not satisfied. But, sure, as long as we don't separate more than we should, then there are benefits to be reaped from doing so.

2) What are the benefits of an all in one app? It seems like with this approach the first thing to suffer is quality, and if that is the case then does not the entire point of digital capturing become null and void? If I wasn't concerned about quality I could have saved myself the large chunks of money I've invested in the needed equipment and just continued to use a $10 analogue card. You're going to need a better argument than bald assertion to sustain the position that integration necessarily means quality must suffer. After all, your "combining" step would be vulnerable to similar arguments, wouldn't it?

3) Where do you guys think the digital capturing process lacks? I'd assume an almost universal response would be dealing with error correction, but what else? I agree that error correction is really important. I also think that we need a process that retains sync information throughout the process. I see that as very important. It is a major failing of AVI, and hence Avisynth, that is does not propagate sync information from the source right through to the containerized final output, and on to the display.

And last, but not least, something that has somewhat puzzled me.
4) Why was it chosen to use DVD2AVI as a base of code and continue with it over starting over? I've said before, and maybe I'm wrong, but the DVD2AVI codebase is rather ugly and give that you seem to have a God-like understanding of how the indexing processes work it seems like it might be benefiicial to start relatively clean. Take the salvagable code from DGIndex and start anew. I'd be careful about calling the DVD2AVI codebase ugly. Sure there are some warts, but the basic architecture is sound and the entirety was very effective and innovative when it was created by jackei. I think the basic soundness of the design is underlined by our ability to relatively easily extend and enhance it as we have done. Software purists may prefer fewer global variables and a more modular structure, but I'll go for pragmatics over purism any day.

And here's another thought for those people that think it's so easy to throw something out and start again: A program evolves over time and adapts to all the strange situations and scenarios that it faces. It accumulates many little bumps and wiggles to handle those things. When you throw out a program you also throw out all that accumulated adaptation. Throwing something out and starting again is not something to undertake lightly.

I'll give an example. Once I decided that the nested parsing architecture of DVD2AVI/DGIndex could be greatly improved. First I thought pipes was the way to go. I implemented it that way and soon discovered information has to flow both ways through the pipes and that made things a lot less simple than I had anticipated. And the performance of pipes is atrocious! I tried another approach and it too ran into an unexpected gotcha. I ended up concluding that, given the needs of the program, the parsing method used is pretty much demanded.

I do think, however, that some areas are in need of redesign. The whole timeline navigation system is very hard to understand and modify, for example. And it behaves in a quirky manner.

Having reached most of the major goals I had in starting DGMPGDec, perhaps now is the time to step back and think hard about what comes next. Maybe I should devote some time to transport stream error resilience, or maybe MPEG1/2 has seen its day, and I should devote myself to MPEG4/H.264. Time will tell.

I would welcome further thoughts from anybody about what directions could usefully benefit from my future development energies.

[GaveUp]

Thank you for taking the time to so clearly express your views. I'll respond to your questions posed at the end.

Yes, the "software tools" approach has a long and illustrious history, and its benefits are easy to see. It carries a danger, however, of separating things that perhaps shouldn't be separated. For example, in an MPEG2 transport stream, there are PTS timestamps that clearly and unambiguously sync the video to the audio. If you demux the audio and video to elementary streams for handling by separate tools, you lose that important information. I suppose you'll argue that after error correction and offsetting, the two stream rates perfectly define the sync, but it is not always so, because it relies upon clocks running very close to their specified values, and we've often seen cases where that requirement is not satisfied. But, sure, as long as we don't separate more than we should, then there are benefits to be reaped from doing so.

Actually, the point you made is more or less exactly what I was trying to get at, although, I do question the feasibility of carrying sync information through the entire process. I would think that using the PTS values at the beginning to fix the streams would work in just about all the cases. The one place where I could see problems is if video frames are outright missing and the audio is intact but at a point where there was no PTS. If that scenario is actually possible, I don't know.


You're going to need a better argument than bald assertion to sustain the position that integration necessarily means quality must suffer. After all, your "combining" step would be vulnerable to similar arguments, wouldn't it?


Yes, I didn't support this enough, but basically what I was saying is as you start adding more and more features into a program it becomes harder to maintain. Additionally, when those features are from two fairly different areas like video and audio it's compounded due to the fact that the developer is likely going to be better at one area over another. It's not to say that this is true in all cases, especially when multiple developers are working on a project, but I think it's a good rule of thumb to use when starting out developement of an application at least. That way you aren't bogged down by I need to add this and I still haven't touched this mentalities.


I agree that error correction is really important. I also think that we need a process that retains sync information throughout the process. I see that as very important. It is a major failing of AVI, and hence Avisynth, that is does not propagate sync information from the source right through to the containerized final output, and on to the display.


I don't know enough about things to offer any input on how to carry sync throughout but I'd honestly be happy if for starters there was something like PX did. Basic silent/last frame replacement for frames with bad crc's, obviously utilizing the PTS as that'd be the benefit of doing it at this step.


I'd be careful about calling the DVD2AVI codebase ugly. Sure there are some warts, but the basic architecture is sound and the entirety was very effective and innovative when it is was created by jackei. I think the basic soundness of the design is underlined by our ability to relatively easily extend and enhance it as we have done. Software purists may prefer fewer global variables and a more modular structure, but I'll go for pragmatics over purism any day.

And here's another thought for those people that think it's so easy to throw something out and start again: A program evolves over time and adapts to all the strange situations and scenarios that it faces. It accumulates many little bumps and wiggles to handle those things. When you throw out a program you also throw out all that accumulated adaptation. Throwing something out and starting again is not something to undertake lightly.

I'll give an example. Once I decided that the nested parsing architecture of DVD2AVI/DGIndex could be greatly improved. First I thought pipes was the way to go. I implemented it that way and soon discovered information has to flow both ways through the pipes and that made things a lot less simple than I had anticipated. And the performance of pipes is atrocious! I tried another approach and it too ran into an unexpected gotcha. I ended up concluding that, given the needs of the program, the parsing method used is pretty much demanded.

I was afraid this might have come across a tad offensive. It wasn't meant as such. I don't mean to slight the program in any way in what it was able to and does accomplish. I'm also quite familiar with the fact that code gets harder to maintain as patches get put in. The wiggles, as you put it, can make things pretty difficult down the road (Oh crap, why did I put that if() in there?).

And I do agree, for the most part, about the pragmatic programming. I tend to do it that way too, but I try as best as I can to do it in small doses for proof of ideas and then clean it up as I go. Otherwise things become a mess quickly. Maybe what DVD2AVI/DGIndex really need is time spent going through the painful process of understanding everything about it and documenting it thoroughly? That might entice more developers to help with things?


I do think, however, that some areas are in need of redesign. The whole timeline navigation system is very hard to understand and modify, for example. And it behaves in a quirky manner.

Having reached most of the major goals I had in starting DGMPGDec, perhaps now is the time to step back and think hard about what comes next. Maybe I should devote some time to transport stream error resilience, or maybe MPEG1/2 has seen its day, and I should devote myself to MPEG4/H.264. Time will tell.

I would welcome further thoughts from anybody about what directions could usefully benefits from my future development energies.

I don't think MPEG1/2 has had it's day yet. Ok, MPEG1 maybe, but with the HD rollout being in MPEG2, at least in the US it seems a while before a change to MPEG4/H.264 would happen since it would require a lot of hardware changes. Not to mention all the disgruntled consumers that only have MPEG2 capable TV's, etc.

Just to clarify. I meant no ill feelings, disrespect, or anything by my ugly comment. I guess a lot of it stems from my frustrations trying to understand it, but it's also not the first time I've heard people voice such frustrations.

[Inc]

Sorry for bumping that up and maybe the decision is already made dropping 2wav decoding.
What about Programstream mpgs out of a Hardware mpeg2 capture device like the common Win PVR 250. IMHO its resulting Programstreams do contain a m2v Video and a mp2 audio stream. It would be nice if DGindex at least could decode the mp2 to wav? I do have no experiences on that as I do not got a PVR capt. card., but maybe someone who uses a PVR can tell how he processes his resulted mpg to be treated by avisynth afterwards inkl. the audio

;).

[nnigam]

I have used 'decode to Wav' just once on an mpeg file I received from a pal country. I love dgindex, and use it for my HDTV processing. There is no better program for maintaining synch. Only rarely do I use hdtvtompeg2 to cut hdtv when I have extra time. I have my master avs script where I just uncomment the needed commands and run the script to process almost anything that I have come across.

In the name of progress, I guess it would be ok to get rid of all the options listed above. You could leave the last version of dgindex that handles them as a download for those needing its functions, and drop them in future versions. I think that would satisfy everyone. As long as dgindex will process any audio on the stream and give me an audio output I would be happy as that is the best way to maintain audio synch when cutting video. I have not used besweet in some time now, but can go back if needed. I have noticed a popping sound when cutting in Avisynth so maybe I am doing something wrong when cutting in vdubmod.

If you are looking for improvement suggestions, I really would like the ability of a high speed scan of the video file to quickly locate sections needing to be cut as well as to get their ntsc/film values.