I suspect you're not understanding how the Mix and Max bitrates work. The minimum bitrate sets the lowest rate that the encoder can encode at.The maximum is the rate that the encoder must not exceed. The average is the target bitrate for the entire encode.

I tested encoding 1 minute of legal black and 1 minute of legal white using 2 pass VBR with the following settings, 2, 5, 8 Mb/sec. Both videos when encoded produced exactly the same file size of 2,010KB. No surprises as nothing in the encoding process cares about vision levels. However that's far from a real world scenario.

The proof of that lies in the results from encoding the same vision at 5Mb/sec CBR. The file size is now 34 MB. In reality the VBR encode isn't correct as the average bitrate is way lower than it should be. Then again there's nothing for the VBR encode to allocated the extra bit budget to.

For a more realistic test I used 1 minute of Vegas generated dancing around noise which is close to impossible to encode.
The results from encoding this at 2 pass VBR 2,5,8 is a file size of 37,536KB.
Encoding CBR at 5Mb/sec gives a file of 37,386KB. So close it doesn't matter.

If you use BitCalc you'll notice that for a given video length the recommended average bitrate for VBR is the same as the value for CBR encoding. In general for typical video the results from using BitCalcs values are close to 98% of target whether you use CBR or VBR.

The advantage of using VBR is that the bit budget can be better allocated. Those portions of the video that contain less motion e.g. static titles are encoded at a lower bitrate than those with fast motion e.g. an explosion.
Certainly if most of your video is slow and dark there's likely to be less motion but the same holds true if your video is slow and bright. The one oftenly overlooked form of motion is noise, the encoder can use a lot of it's bit budget encoding noise. Depending on several factors even slow and dark video can contain a lot of noise if the camera has upped the gain.

Bob.

Let me see if I get I can get this right.
Your project fails during the encode phase. That's when the menus are encoded and they're encoded at the project bitrate. I'd also guess the process might pull some other data from the project's properties to wrokout the format of the encode.
Possibly whatever the encoder is being told to do isn't compatible with the BD spec or it tries to retrive some value that plain isn't in the project property.
One thing to check is all the ptoject properties and also the project bitrate. Also check what you have in the summary tab of the project properties.
Based on where the problem is occuring I doubt it's anything to do with subtitles, they're muxed in during the next phase of the build I think.

Bob.

Bob,

My understanding of VBR vs CBR has been absolutely the same as yours. The difference in encoding e.g. 25 CBR vs e.g. 20/25/30 VBR is that while having more headroom for high action (35 Mbps), the VBR can yield better results than 25 CBR, while producing a smaller file (depends on the contents - but if it allows, it will be encoded at 20 vs 25 Mbps of the CBR). Two-pass VBR can even increase those differences (i.e. quality/size ratio).

Bob & Blink,

I'll try to be clear this time, although please remember English is not my first language:)

My BD project certainly does NOT fail due to its media bitrate used, as these same media render just OK in a separate project, without any menu structure apart from the single-page, starting menu that each DVDA project starts with by default.

Yes, at first I just changed my (working) DVD project properties to BD and replaced my media files with their HD versions. Since it didn't work whatever I did (like removing graphics, and even whole menu branches, one by one), I started a fresh BD project.

As I said, with just 4 links to my HD media, it rendered. Once I added my first background graphics to the top menu, it wouldn't render. However, after saving the project and re-launching DVDA - it rendered again...

So now I'm just re-creating my (working) DVD project one step at a time. When I have it ready, and DVDA can still render it - I'll let you know:)

PS. This is something even more outrageous that the intricacies of keeping aspect ration, when down-converting from HD to wide-screen DVD in Vegas!

"However, after saving the project and re-launching DVDA - it rendered again..."

That sounds familiar. Way back ,can't remember how far way back, one trick to get DVDA to play nice was to save, close and open to clear problems.

"Once I added my first background graphics to the top menu, it wouldn't render."

What is ths background graphic exactly and what dimensions. Is it a psd file? If so maybe saving it as a PNG or jpeg or even making a copy and flattening the layers would help.

Bob.

Dear Bob,

All my backgrounds are jpeg's.

Right now I'm rendering my HD project - hope it will succeed.

However, since adding one asset at a time, saving/closing/opening is quite tedious, I have made this projects less complicated than its DVD counterpart, by one menu level (in the original DVD project, the fist menu appearing on screen has been the Polish vs English language version choice; if a viewer chooses English, the English subtitles are activated by default in all relevant media assets).

For my own use, it's not necessary; however -- if my DVD is a commercial success :), we'd like to re-print in HD - so making this lang selection menu work is important. The tricky part about is has been that the DVD menu structure was sort of doubled, with all the branches under the "Polish" choice having been right-clicked, dragged under the "English" menu branch, and inserted as links (so that DVDA didn't create double physical copies of media). Then, as the last stage, the default behaviour was changed (subtitles OFF for the Polish, ENG for the English version).

As I said, using step-by-step method (with many DVDA savings / closings /re-openings in between), I managed to render a "single language version" of my BD. I wonder whether those links in the English part of menu structure we at fault - they worked fine with DVD?

Update:

The render FAILED with the following error message:

"File name: N/A

Now, I'm really lost :)

You're not using any files in the project whose names contain non English characters by any chance?

Bob.

No - I have paid great attention to it, Bob.

As a tidbit: it's enough to change a menu name in the project to "render" it "unrenderable"!

However, once saved and re-loaded, it tries to render again, which is a good news. Thank you so much, SCS !

Gosh.

So it just failed again, but this time I took a beer and was watching it carefully:

- the stage "Generating MUI": passed
- the stage " Preparing compilation (processing file 00002.m2ts)" failed at some 35 %.

And here is what I suspect: judging from my BD structure, the 00002.m2ts file is the main movie (concert.m2v and its associated, 24/48 concert.wav); even before failure I noticed DVDA was estimating the time needed fro this phase to be 1:30:00 - one and a half hour! I don't remember anything taking that long in my DVDA compilation (OK, this is HD - but still to long - and indeed it failed).

Any clues? The same m2v/wav combitation rendered completely (and quickly) in a separate BD project!

Hi, Piotr. I really hesitate to jump here. I've read this thread several times in an effort to understand the problem. After several readings (some last night and some this morning), I don't really have anything to offer in the way of advice.

If I understand, setting compression variables and issues aside, your problem is:

1. You created a project in SD and successfully burned it to DVD.

2. You created an HD version of the same project (without any variables), attempted to burn it to Blu-ray, and DVDA recompressed the video files, and gave you an error message.

As brief as it is, is that an accurate description of the problem?

"Any clues? The same m2v/wav combitation rendered completely (and quickly) in a separate BD project! "

I'm completely out of ideas other than to say again if you encode all video to a BD template and your problems go away there's a clue there.

Not to say there isn't a bug, indeed that's very likely. One has to wonder if you're not the first person on the planet to attempt exactly this with DVDA.

I fear you're probably going to have to wait for SCS to get to the bottom of this problem. Based on how long it took in the past to get the numerous bugs fixed in DVDA I'd seriously suggest taking on board some of the early suggestions.

Bob.

"As brief as it is, is that an accurate description of the problem?

No Jay, and apologies fro my English again :)

DVDA never had to re-compress my m2v or wav media files, as they've been well within the BD specs.

However, there are 2 (seemingly separate, but perhaps somehow connected) types of problems with my HD project version:

1. Adding or modifying anything in it (a menu page, menu background, a link - etc) makes it un-preparable until I save it, close and re-start DVDA (could live with that one)

2. The "preparing compilation - processing file 00002.m2ts" stage takes ages (over an hour estimated by DVDA), and fails at some 35%.

So, now we're back again too the media compatibility. My video is VBR 35/25/20 Mbps; what should the BD project properties be? 40, 35, or perhaps 25 Mbps ? In neither of these setting does DVDA want to re-compress my video, but at 40 Mbps it failed, and now I'm trying to render it with just 25Mbps project setting (again, no re-compression of my 35/25/20 VBR m2v's was said to be necessary)...

A queestion of its own:

Why doesn't DVDA re-compress my VBR 35/25/20 Mbps video files, regardless on the general project bitrate setting?

Whether the latter is set to 18, 25, 30 or 40 Mbps, it says my m2v's don't require re-compression (and then fails right after processing the m2ts files), displaying error message:

"File name: N/A"

Boy, I'm at a loss, Piotr.

Hopefully, the folks at SCS will have an answer for you soon.

How many titles are you preparing for disk... is it just one... or more?

4

Are all these titles the same bitrate, the same file type and are they all showing no recompress... or at least the OPTION for no recompress?

Yes blink,

all 4 are exactly the same bitrate and resolution, with their accompanying audio also being the same format for all the 4.

DVDA doesn't need to recompress any of them (neither video, nor audio) - even with the project setting of 40 Mbps.

They occupy almost 20 GB space.

I think that DVDA ignores the bitrate settings for both video and AC3 when it is fed compliant files - that has been my experience since version 2 or 3 with SD and now with HD in 5.0. I think it's designed that way.

However, I suppose it's possible that there could be a bug in it that causes a crash at certain set bitrates. have you tried leaving it at the default BD bitrate (which I think is 18) - do you get the crash in that case?

Blink: you said "Not necessarily.
CBR will deliver a steady constant stream of bits evenly spread throughout your video, while VBR uses MORE bits in bright high action scenes, and LESS bits to darker, slower shots."
My point was that if the average is 35 in a VBR render, the final file size will be more or less the same as a 35 CBR file, the difference being that the bitrate will vary within the different parts of the file, depending on the information. But the total "number of bits" in the file will average out to be (roughly) the same.

megabit:

If this is the case and you choose NO RECOMPRESS for your files then the only thing your project setting bitrate will affect is the bitrate for your menus and such... which ideally you should set at the same rate as your videos.

In other words when you set the project bitrate at 40M and set your videos for no recompress.... the only thing that get burned at 40M is your menus.

And speaking of 40M... you should avoid burning at this rate. 40M is Blu Ray's MAXIMUM rate. Bitrates are rarely ever steady so when you set at 40M your bitrate always goes up and down just a bit.... even in cbr the bitrate changes just a bit. If you shoot up over 40M just ONCE you now have a disk that is non compliant. Set for 35M max... this will give you a bit of head room.

"My point was that if the average is 35 in a VBR render, the final file size will be more or less the same as a 35 CBR file, the difference being that the bitrate will vary within the different parts of the file,"

I agree.
After listening to both you and Bob (and doing my own little experiment) it is clear that the file sizes ARE in fact the same (or close to it anyway) and I stand corrected on the subject.

"And speaking of 40M... you should avoid burning at this rate. 40M is Blu Ray's MAXIMUM rate"

blink, isn't the maximum 48 Mbps?

I guess that the 40Mbps which is the maximum you can enter into project properties, is already lower than the theoretical max for the very reasons you mention...

Ad thanks for explaining to me where the project setting's bitrate is used when I choose not to recompress media - makes sense :


Piotr

PS. I have just succeeded burring the HD version of my DVD - stunning pictures (I used VBR at 35/25/20). Thanks to DVDA's remarkable consistency, speed, and stability ;), it only took me 4 days to build a workable BD version of my ready (ad working) DVD project.

SCS, you're reading this for sure - please answer my ticket about the woes DVDA has given me wit this; all the additional info you engineers might need can be found in this thread... Please don't use any automated answers like "reinstall DVDA", or "make sure you have enough disk space". Thank you

Piotr

CBR will deliver a steady constant stream of bits evenly spread throughout your video, while VBR uses MORE bits in bright high action scenes, and LESS bits to darker, slower shots.

As usual, when you turn to technical matters, you are wrong blink. If VBR and CBR at ostensibly the same bitrate is not the same file size, then the VBR file didn't have the same average bitrate as the CBR file. It is simple maths blink. 4 + 0 + 2 = 2 + 2 + 2.

But hey, even when SCS comes out and tells you you are wrong about their product you don't believe them, so I won't expect you listen this time either.