Does anyone use "Process WAV"?

[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.