The re-rendering of a V1 project is a known problem. If you just create a new V2 project and add in all your assets, it won't re-render the files.

Information required to make a more accurate space used estimate can only be determined though computationally or disc intensive operations (rivaling that of the prepare itself). So, with incomplete information, we fail on the side of estimating too big (for obvious reasons).

The estimated burning time left is not always accurate because of technical limitations in determining the estimated time for burning the lead in and lead out. As such, most burning applications do not provide time remaining estimates while burning the disc's lead in and lead out. We have considered doing the same.

I agree that some improvements could be made to the estimated time during the prepare stage.

As far as we know, there are no inconsistency with what the Optimize DVD dialog and the actual render. If you have a project which you're sure is doing this, let us know and we can provide an FTP site for upload. Thanks.

If you make a change to the now reencoded project. (a menu modification)
it should only reeencode the menu, but it says it wants to reencode everything.

I am running out of time on this project and now must waste 5 hours reencoding again.

Can I get through this reencoding bug soon? Any work arounds?

This is not a bug: all non-DVD compliant source is rendered each time you prepare. But I do agree it would be useful.

1. I am baffled as to why it is difficult to estimate, in advance, how much disk space will be required for a given project. The MPEG and AC3 files, if they already exist, are known sizes. The output of any files that must be encoded can be known precisely (based on bits per second of the encoding rate). The overhead structure of a VOB file is knowable.

2. I am a little more forgiving on the problem in estimating time remaining for rendering and preparing. However, I still believe that the estimates on how much time it will take to prepare a project clearly can be done better. For instance, I have seen DVDA 2.0 estimates that almost immediately (in less than five seconds) show that the prepare process is 60% complete, but then the process takes another half hour.

The render time for any given render operation is knowable once a few projects have been rendered. The prepare time is also knowable, although it can vary depending on whether the render is done to the same disk or to a physically different disk. I would suggest adding code that remembers these times and then uses them for future renders.

3. Burn time estimates. Clearly DVDA 2.0 has significant problems here. The burn process is completely cut and dried, and the numbers should be dead on. At 1x, it takes one hour to completely fill a 4.7 GByte DVD. If I only have to fill it halfway, it will take thirty minutes. At 2x, the times are exactly half this. Granted, there are some overhead times (lead-in, lead-out, etc.), so the equation isn't exactly linear, but it is pretty close to a simple y = mx + b equation. If you measure the time it actually takes, and then use that time during future burns, you can even eliminate variations between drives.

Before I go on to the last topic, I should point out that my assertions in the above paragraphs are not some arrogant assertion by some armchair programmer, but are instead based on observation of competitive products. Both MyDVD and MovieFactory estimate project size correctly, and give accurate estimates of remaining burn time (as does EasyCD Creator and Nero). Therefore, I know that this can be done. The only process where other products also don't do a perfect job (although they do a far better job than DVD 2.0) is estimating remaining render and prepare time.

4. As far as we know, there are no inconsistency with what the Optimize DVD dialog and the actual render. I have done some more testing, and I have found out what is going on here. Like some of the other problems I have reported to tech support in the past few days, it has to do with the Music Compilation feature. This is admittedly a pretty subtle "issue" (I don't think it quite rises to the level of a "bug").

What happens is this: If you put several MPEG/AC-3 file combinations into a Music Compilation, and some of the AC-3 files are 5.1 and some are two channel, but all of them are "legal" files that, if put into a menu compilation, would not require recompression, then your Optimize dialog shows that no recompression is required. However, recompression (i.e., rendering) DOES occur. Once I realized what was going on, I completely understood: Since all the files are being combined, they have to all be converted to a single, uniform format. It appears that the audio format chosen is the project format. This is the correct behavior. However, you should put an asterisk or a yellow mark in the Optimize box to indicate that SOME of the audio files will need to be re-rendered.

I suspect the same issue might occur if the AC-3 files were all stereo or all 5.1, but the MPEG2 files were encoded at different rates, although I haven’t tested this.

1. You're assuming all the data in an MPEG file is burned to DVD. However, for instance, an MPEG file contains system layer data which is discarded and the size of which is unknown. Also, the average bitrate of a video stream in an MPEG file is not precisely known. The MPEG file stores the maximum bitrate but not the average bitrate. To determine, the average bitrate the entire stream would have to be read.

2. Yes, as I stated before, I agree that this can be improved.

3. The numbers could be dead on if we didn't try to account for the lead-in and lead-out. For instance, Nero does not show an estimated time and does not show progress while burning lead in/lead out. The overhead for burning lead in/lead out is not a constant. For instance, when burning a DVD-RW, the lead-out can take anywhere from close to 0 to 15 minutes. I'm thinking more and more that DVDA also shouldn't show progress for lead-in/lead-out.

4. You'll notice that in the Optimize DVD dialog the properties for your music compilation will have the "Compliant" field set as "Indeterminate". This means some are compliant with the "Type" in the "Recompress settings". Also, the "Recompress" field is set to "Auto". This means only the non-compliant files will be recompressed. For this situation, I agree that we should show a different icon in the list view.

I created my first DVD in DVDA2 last week and I noticed that even though I had apparently properly encoded my video and audio in Vegas 5 (the Optimize DVD window didn't flag any problems) and did not add any other clips to the DVD, it still took as long to encode the DVD in DVDA2 as it did to render the original MPG file in Vegas 5. What I surmized was that since I used an animated button for the clip (actually two - a direct one and a scene selection one) those animations had to be rendered/encoded by DVDA2. Is this what was happening? And am I then correct in assuming that animated button will always add to my render time?

I then correct in assuming that animated button will always add to my render time?

Yes, and it can also add considerably to the space required. There were posts several months back, from someone who had assigned the entire movie file to the button. This meant that the entire movie had to be rendered down to button size. This took days (because he had several buttons), and the resulting files were quite large.

If you are going to use video for animated buttons, you should create a short video clip in Vegas, and use that for the button.

I am burning my first "complicated" DVD with the new version. It is a first play, Main menu, which contains links to two movies and two subs menus. Each of the submenus has several text type buttons, each linked to individual movies. All the motion backgrounds are made from the Sony Motion Backgrounds with Acid Pro 3 00:15 long AC3 files for audio. So far so good.

All media is DVD-A WS Video only with AC3 audio. There wasn't very much time spent on recompression. However, I agree with John Meyer on the misleading burn time estimate. I did a 7 minute DVD before I went out to a meeting and though DVD-A predicted 32 minutes to prepare render and burn, it took just 13:00. Now I am watching the program burn the tracks and the time estimates keep jumping from 45 minutes remaining (arrgghh) to 25 (crosss fingers) THis is a bit bizarre because I do not know when I will be able to come downstairs to test the disc.

What I have noticed , and it really is not a problem for me at least, is the program requires a PC with serious horsepower. I gave up trying to do this project on my office 1.7 /512 RAM becasue it took forever to Preview or size buttons. Solution: since I have to present this to the Apprenticeship COmmittee tomorrow at 0830 I put everything on a Lacie and am building the disc here at home. I'll finish burning this, PRAY the navigation works and if it does't, well, I guess I'll start over with Encore. Hope I don't have to though!

Peter

What a pleasant surprise - it finished 20 minutes earlier that estimated AND plays flawlessly in the Koss, Pioneer Industrial and that Sony RG7(?). Making a disc image then leave the stack of DRX 510s to make me four additional copies for the meeting. Thank you Sony! You make excellent Broadcast video and audio gear and now you have turned DVD Architect into a serious program. I will never, ever use ReelDVD again for any reason and Encore won't getting much use either.

Peter

you have turned DVD Architect into a serious program

I definitely agree. Even though I am finding quite a few bugs, and even though I think the program definitely does not run smoothly with "only" 512 Mbytes of RAM, it is still a remarkable improvement from version 1.0, and a serious competitor to any program in its price range (or below).

Would setting in and out points on the animation video file in DVDA2 help cut down on the rendering time?

The video was re encoded by DVDA2 all files that were generated should
be recognized as compliant. Only the menu should need to be re encoded.