BD-Rebuilder, Feature Requests

[Lathe]

Speaking of quality presets, since I rebuilt my PC, I keep the AUTO_BIAS=3. When making BD25's I rarely see much difference in the quality chosen.

While I don't need everything done on 'Very Slow', most things end up normal or faster. It would be nice if there was more of a separation... or a AUTO_BIAS=4.

Yes, I second this also... a choice to lean the bias more toward quality would be nice. For me personally, if a BD is fairly large, I will most always choose 'High Quality' 2 pass; however, there are numerous cases where I WANT to allow the 'Auto' feature to do it's thing and I also set the AUTO_BIAS=3, but I too feel that it doesn't seem to tweak it that much towards quality.

In other words, if I felt that the auto_bias could be set stronger for 'Quality', I would probably be more inclined to use the 'Automatic' setting rather than 'second guessing' it and just setting it higher.

Thanks!

[Lathe]

Thank you, for consideration and I really appreciate it.

Thank you from me too; I don't really go for total overkill as a rule, but it will be interesting to play around with it. I'll hafta re-check to remind myself if 'Slower' is still compatible with Blu-ray. That is likely the highest I would try...

[Sharc]

Out of curiousity: Has anyone found real and visible qualitiy deficiencies with the current Auto-Quality settings? Examples? Scenarios?
Seeing no difference between AUTO_BIAS=3 compared to default means that the default is already very good and leaves probably only marginal room for improvement.

[mparade]

According to "Lastcmd" contents weightp appear after --bluray-compat but x264 still doesn't accept it's value.



When I check with media info it says weightp=1 and no I didn't modify file.
On a side note I don't see qpfile anymore for chapters, did you remove that?


Maybe, this the reason:

"bluray-compat
...modify x264's options to ensure better compatibility with all Blu-Ray players. Only neccessary if your video will be played by Blu-Ray hardware players.
This setting makes some option changes:
## Cap --weightp at 1"

But I do not understand, either as this option follows bluray-compat in the command line.

[Sharc]

Maybe, this the reason:

"bluray-compat
...modify x264's options to ensure better compatibility with all Blu-Ray players. Only neccessary if your video will be played by Blu-Ray hardware players.
This setting makes some option changes:
## Cap --weightp at 1"

But I do not understand, either as this option follows bluray-compat in the command line.
I think to remember that --bluray-compat is given priority, irrespective whether it is put at the beginning of the commandline or not. Means whichever conflicting parameter preceeds or follows is discarded. This is different from the presets (like --preset medium) for which the parameters are overruled by subsequent settings.
There has been a discussion about this long time ago but I didn't find the posts.
This would explain why --weightp 2 is not effective.

In case of interlaced (MBAFF) encoding --weightp is not supported, i.e. always --weightp 0 in this case.

[mparade]

I think to remember that --bluray-compat is given priority, irrespective whether it is put at the beginning of the commandline or not. Means whichever conflicting parameter preceeds or follows is discarded. This is different from the presets (like --preset medium) for which the parameters are overruled by subsequent settings.
There has been a discussion about this long time ago but I didn't find the posts.
This would explain why --weightp 2 is not effective.

In case of interlaced (MBAFF) encoding --weightp is not supported, i.e. always --weightp 0 in this case.

Yes, this would explain that, thanks for the clarification.

[Sharc]

As concerns the --presets I found this table (http://dev.beandog.org/x264_preset_reference.html)quite helpful.
I am however not sure if anything has been changed in x264 in this respect since.

[mparade]

As concerns the --presets I found this table (http://dev.beandog.org/x264_preset_reference.html)quite helpful.
I am however not sure if anything has been changed in x264 in this respect since.

Thank you very much. It is very very useful.
Do you know why we are forcing the following parameters in the command line?:

- -- vbv-maxrate 35000 (Blu-ray specification specifies a 40 Mbit maximum data rate for the video)
- -- ipratio 1.1 (MBTREE calculates the optimum value automatically through the preset)
- -- pbratio 1.1 (MBTREE calculates the optimum value automatically through the preset)

Your reply would be really appreciated.

[jdobbs]

Out of curiousity: Has anyone found real and visible qualitiy deficiencies with the current Auto-Quality settings? Examples? Scenarios?
Seeing no difference between AUTO_BIAS=3 compared to default means that the default is already very good and leaves probably only marginal room for improvement.You shouldn't see quality differences in auto. That's the point. It looks at your source and only goes as far as it needs to in order to get top quality. If a lower settings is all you need, then it uses that one and saves time. If it needs a higher one -- it goes for it.

[Sharc]

Thank you very much. It is very very useful.
Do you know why we are forcing the following parameters in the command line?:

- -- vbv-maxrate 35000 (Blu-ray specification specifies a 40 Mbit maximum data rate for the video)
- -- ipratio 1.1 (MBTREE calculates the optimum value automatically through the preset)
- -- pbratio 1.1 (MBTREE calculates the optimum value automatically through the preset)

Your reply would be really appreciated.
Well, my assumptions only (jdobbs would know better of course)
--vbv-maxrate 35000: probably a safety margin due to some bad experience (stutter) with 40000. You won't see a quality difference though as the video peak rate of 35000 will rarely happen in backup compression scenarios.
--ipratio and --pbratio: it is discarded when --mbtree is activated. So it does not matter to leave it there. But depending on the preset --mbtree gets deactivated and --ipratio/--pbratio kick in. The default values in x264 are 1.4 and 1.3 respectively. Long time ago it has been changed in DB-RB to 1.1 in order to reduce GOP pulsing for heavily compressed material. Maybe it could now be left at the default value since x264 has been improved since. You may want to test yourself.

.... jdobbs was faster :D

[jdobbs]

Thank you very much. It is very very useful.
Do you know why we are forcing the following parameters in the command line?:

- -- vbv-maxrate 35000 (Blu-ray specification specifies a 40 Mbit maximum data rate for the video)
- -- ipratio 1.1 (MBTREE calculates the optimum value automatically through the preset)
- -- pbratio 1.1 (MBTREE calculates the optimum value automatically through the preset)

Your reply would be really appreciated.Because you have to comply with the blu-ray standards. I spent a lot of time with the BD specification in my hand and a lot of tests from users on many standalone players to make sure the settings are all correct and will play without issues on all players. I'm not going to now go over each and every option again and debate why it it there.

If you go back through the entire bug thread you'll find reasoning for all...

[Sharc]

You shouldn't see quality differences in auto. That's the point. It looks at your source and only goes as far as it needs to in order to get top quality. If a lower settings is all you need, then it uses that one and saves time. If it needs a higher one -- it goes for it.
That's what I experienced :cool:
I was just wondering why people strive for 'even better' settings and whether there is a real reason for it.

[jdobbs]

That's what I experienced :cool:
I was just wondering why people strive for 'even better' settings and whether there is a real reason for it.That's one I'll never be able to explain. What is the point of "making sure I have the best quality" if you can't see the difference?

But... to each his/her own. Differences in people are what make life interesting (and confusing).

[CV91913]

I just got a new phone (Windows 8) which does not support MKV and the Windows app store has a dearth of good video players that do. So I am converting a bunch of my MKV videos to MP4. Your software does a great job of this. My question/request regards audio. The device only supports AAC. What I noticed is that in the process of creating the psudo BD structure the existing AAC is converted to AC3. I understand why you do this but I wonder if there is a way to avoid this? Some switch or setting? I currently have an alternate output section that leaves the video intact but I have to force the AAC audio output. Between the conversion from AAC to AC3 and then back to AAC, it adds about 10-12 minutes to a 35 minute process. I would like to have the process be able to leave both the audio and video intact and just do the package conversion. Thanks...

[laserfan]

I like the idea. But I'm not sure whether the time constraints would make it feasible. It may be something that could be enabled with a hidden switch. I'll do some testing.

You shouldn't see quality differences in auto. That's the point. It looks at your source and only goes as far as it needs to in order to get top quality. If a lower settings is all you need, then it uses that one and saves time. If it needs a higher one -- it goes for it.

Still, you must not be COMPLETELY happy with AUTO_QUALITY=1 if you liked DoctorM's test-for-success idea earlier. Or maybe you just see it as a challenge.

IMO if someone wants a perfect copy for their normal viewing/backup then they just choose a BD-50 or BD-25 as appropriate & don't reencode at all.

[jdobbs]

I just got a new phone (Windows 8) which does not support MKV and the Windows app store has a dearth of good video players that do. So I am converting a bunch of my MKV videos to MP4. Your software does a great job of this. My question/request regards audio. The device only supports AAC. What I noticed is that in the process of creating the psudo BD structure the existing AAC is converted to AC3. I understand why you do this but I wonder if there is a way to avoid this? Some switch or setting? I currently have an alternate output section that leaves the video intact but I have to force the AAC audio output. Between the conversion from AAC to AC3 and then back to AAC, it adds about 10-12 minutes to a 35 minute process. I would like to have the process be able to leave both the audio and video intact and just do the package conversion. Thanks...The problem is that when it imports it has to convert to a format that is compatible with Blu-Ray. AAC is not compatible.

It's just a matter of using MKVEXTRACT to get the elementary streams and then MP4BOX to remux it into the MP4 format (both are included in the BD-RB package). I could probably could a function that imports directly from MKV to MP4 and vice-versa, but I'm not sure whether it's really within scope of what BD-RB is designed to do (go in-and-out of a BD structure).

[jdobbs]

Still, you must not be COMPLETELY happy with AUTO_QUALITY=1 if you liked DoctorM's test-for-success idea earlier. Or maybe you just see it as a challenge.

IMO if someone wants a perfect copy for their normal viewing/backup then they just choose a BD-50 or BD-25 as appropriate & don't reencode at all.I've done some limited testing of that concept -- and so far it doesn't appear feasible. Using Q or CRF isn't a good measure, as I'm finding that going to a higher/slower quality level using the same bitrate doesn't necessarily decrease the Q. In fact it appears to sometimes increase it. I have found, however, that using a fixed CRF and increasing the quality level (for example from GOOD to HIGH QUALITY) decreases the size while maintaining roughly the same Q -- which is interesting. Maybe something like PSNR might be a better measure, I'll keep playing with it.

I am satisfied with how it works now... but that doesn't imply I should dismiss possible improvements, does it?

[CV91913]

The problem is that when it imports it has to convert to a format that is compatible with Blu-Ray. AAC is not compatible.

It's just a matter of using MKVEXTRACT to get the elementary streams and then MP4BOX to remux it into the MP4 format (both are included in the BD-RB package). I could probably could a function that imports directly from MKV to MP4 and vice-versa, but I'm not sure whether it's really within scope of what BD-RB is designed to do (go in-and-out of a BD structure).
OK, I understand. Just thought there might be a "hidden option" I am unaware of. Thanks for the response.

[CV91913]

It's just a matter of using MKVEXTRACT to get the elementary streams and then MP4BOX to remux it into the MP4 format (both are included in the BD-RB package)..

Yes, that works like a charm. Takes about 10 minutes. I should have thought of that, I even have GUIs for both of those tools. I have just gotten so spoiled with the added functionality of BDRB, I just fire it up without thinking. Keep up the good work!

[Lathe]

As concerns the --presets I found this table (http://dev.beandog.org/x264_preset_reference.html)quite helpful.
I am however not sure if anything has been changed in x264 in this respect since.

That is helpful; thanks Sharc. As was mentioned earlier, the 'Slower' preset begins to set things that conflict with Blu-ray compatibility, as far as hardware players are concerned. Also, per your earlier comment about 'seeing' the difference (although you were referring to the 'Auto' preset and 'Auto_Bias') to me personally the subme=9 is indeed approaching overkill, thus I never use the very 'Highest' setting on BDRB because that DOES take quite a bit more time I feel for no discernable return.

So, what I personally do with my more critical BDRB settings if say the Blu-ray is one with a lot of detail or the visuals are especially important, I use the default 'High Quality' setting 2 pass, BUT, I include a few of the 'higher' tweaks in the 2nd pass such as the Deblock settings (Tune--Film) Trellis and Psy settings to give it that little extra visual 'bump' (BTW, I've always been kind of surprised that none of the BDRB settings include the Deblock -1,-1 or Tune--Film settings - I would THINK that with most Blu-ray backups people would want that, but maybe not) But, across the board, the 'Slower' settings by and large are probably not really that discernable for a LOT more encoding time.

And, what you were saying before about really 'noticing' the difference between the Auto setting with or without the Auto_Bias=3, is kind of the point that I made earlier, that it would be kind of nice to be able to tweak the Auto settings more so towards quality, if possible. Then, I think with the slightly more demanding encodes, one would be more comfortable using the Auto setting. Just my lowly and wretched opinion...

[omegaman7]

I've used the slowest settings, and seen visible differences. But that also depends on decoding/player CPU/GPU rendering. "The Other Guys (http://www.imdb.com/title/tt1386588/)" comes to mind. Some of the black levels, were really blocky at times. Unless I ran it at slowest settings. That was early on in development. It's possible that that has changed for whatever reason.

[Sharc]

........ as I'm finding that going to a higher/slower quality level using the same bitrate doesn't necessarily decrease the Q. In fact it appears to sometimes increase it.......
This reminds me on the observation made some time ago by a poster telling that going to slower quality settings did in fact increase the color banding :eek:

[Sharc]

I've done some limited testing of that concept -- and so far it doesn't appear feasible. Using Q or CRF isn't a good measure, as I'm finding that going to a higher/slower quality level using the same bitrate doesn't necessarily decrease the Q. In fact it appears to sometimes increase it. I have found, however, that using a fixed CRF and increasing the quality level (for example from GOOD to HIGH QUALITY) decreases the size while maintaining roughly the same Q -- which is interesting. Maybe something like PSNR might be a better measure, I'll keep playing with it.

I am satisfied with how it works now... but that doesn't imply I should dismiss possible improvements, does it?
Maybe a faster alternative to DoctorM's proposal for a quality-based encoding could be:
- Run a full CRF encode at a fix CRF in pass 1 and produce a stats file
- Compare the resulting bitrate with the target bitrate, and adjust the quality settings depending on the deviation (some experience factor comes in here)
- Run pass 2 with the stats from pass 1, the new quality settings and the target bitrate.

Encoding time would be similar to a regular 2-pass with slow firstpass.

[laserfan]

I am satisfied with how it works now... but that doesn't imply I should dismiss possible improvements, does it?
Of course not, I was just curious about it because I really have no idea about what is behind the AUTO_QUALITY setting.

I am certainly all for settings that take the guesswork out of making decisions--I am agnostic regarding the use of discs, though I guess when I think about it, the least favorite of recordable discs is the double-layer type ie the DVD-9. I like DVD-5 because they are cheap & reliable and while I may be wrong about this I prefer them against dual-layer just for the added simplicity of them. Then BD-25s are terrific but are only readable in BD players...

It would be great though if your testing would lead to BD-RB actually making a recommendation on which type to use for a movie, based on a test run of some sort. Right now my thinking is as simple as "this is a blockbuster filled with awesome visuals and SFX, so let's use BD-25" or "this is a short movie i.e. 100min and a simple drama, just use DVD-5".

Funny, if the stupid studios didn't author their discs with such horrible startup junk, i.e. if every disc simply started with the movie-only, no warnings or promos or trailers or ratings junk, then went-to-menu after, I would not have to use BD-RB at all, and only do backups for movies I would give to the kids to watch over & over again, and destroy eventually... :p

[DoctorM]

Maybe a faster alternative to DoctorM's proposal for a quality-based encoding could be:
- Run a full CRF encode at a fix CRF in pass 1 and produce a stats file
- Compare the resulting bitrate with the target bitrate, and adjust the quality settings depending on the deviation (some experience factor comes in here)
- Run pass 2 with the stats from pass 1, the new quality settings and the target bitrate.

Encoding time would be similar to a regular 2-pass with slow firstpass.
If x264 is anything like mpeg-2, using data gathered from a first pass at a different bitrate than the second pass degrades the quality more than if you just did another single pass at a new value.

[Sharc]

If x264 is anything like mpeg-2, using data gathered from a first pass at a different bitrate than the second pass degrades the quality more than if you just did another single pass at a new value.
Yeah, I remember vaguely that this has been discussed long time ago for x264. IIRC the deviation tolerance was in the order of 10% maximum which is probably not sufficient for this purpose. I tried to find the posts, but no avail ...

[HWK]

Yeah, I remember vaguely that this has been discussed long time ago for x264. IIRC the deviation tolerance was in the order of 10% maximum which is probably not sufficient for this purpose. I tried to find the posts, but no avail ...

Yeah, I remember reading Jason post and it mentions this as well. Although it make a difference but it is negligible and can be ignored.

[Sharc]

Yeah, I remember reading Jason post and it mentions this as well. Although it make a difference but it is negligible and can be ignored.
Aaahh, Jason aka Dark Shikari, right?
Yes, now I remember that he once mentioned that it should even be possible to do pass 1 with a lower resolution in order to speed the generation of the stats file up. However, the proposal seems never have materialized.

[Added:]
Finally I found something here (http://forum.doom9.org/showthread.php?t=161644)and here (http://forum.doom9.org/showthread.php?p=1448147%20-%20post1448147)in this context.
It seems that the stats file is quite "robust" w.r.t. changes for the 2nd pass.

[mparade]

@jdobbs

Is hybrid material processed by BD-RB the same way as the interlaced? I am a bit unsure regarding hiddenopt ASSUME_HYBRID.

Your help would be appreciated.

[jdobbs]

@jdobbs

Is hybrid material processed by BD-RB the same way as the interlaced? I am a bit unsure regarding hiddenopt ASSUME_HYBRID.

Your help would be appreciated.Almost, but not exactly. To process a hybrid source you have to instruct the decoder to honor pulldown flags or to make adjustments to assure the framerate is correct.

[mparade]

Almost, but not exactly. To process a hybrid source you have to instruct the decoder to honor pulldown flags or to make adjustments to assure the framerate is correct.

Does BD-RB automatically instruct the decoder after performing the MPEG-2 extended scanning routine or do I have to make some evaluation on the material like on a "hard telecined" source and then instruct the program through the hiddenopt ASSUME_HYBRID? As far as I remember, the hybrid sources are marked with "***" after the fps mark in the stream tab and "*" marks the soft telecine pulldown material, although I have never seen "*" so far inspite that I am working with "a lot of" 3:2 pulldown sources.

Thank you very much for your help in advance!

[jdobbs]

Does BD-RB automatically instruct the decoder after performing the MPEG-2 extended scanning routine or do I have to make some evaluation on the material like on a "hard telecined" source and then instruct the program through the hiddenopt ASSUME_HYBRID? As far as I remember, the hybrid sources are marked with "***" after the fps mark in the stream tab and "*" marks the soft telecine pulldown material, although I have never seen "*" so far inspite that I am working with "a lot of" 3:2 pulldown sources.

Thank you very much for your help in advance!BD-RB does it automatically. As for "hard telecined" -- BD-RB has no way of know that. In that case you have to force telcining by using IVTC_480i.

The "*" markings in the streams list are based on a very short scan of the beginning of the file... the true nature of the disc is known only after the full MPEG-2 scan that happens during processing.

[mparade]

If someone was ever interested in.

[Sharc]

Suggestion for 1-pass crf prediction mode:
- Generate and keep the --stats file of the --crf pass.
- If the file becomes oversized: Run --pass 2 automatically with the stats from pass 1 and the target bitrate.

Oversizing (or heavy undersizing) using BD-RBs prediction mode is seldom, but it happens maybe in 1 of 10...20 cases.
I tried above method. It seems to work very well without any noticeable quality loss due to the bitrate correction for pass 2. I think it's more reliable than repeating the encode with an educated guess for a new --crf.

[jdobbs]

Suggestion for 1-pass crf prediction mode:
- Generate and keep the --stats file of the --crf pass.
- If the file becomes oversized: Run --pass 2 automatically with the stats from pass 1 and the target bitrate.

Oversizing (or heavy undersizing) using BD-RBs prediction mode is seldom, but it happens maybe in 1 of 10...20 cases.
I tried above method. It seems to work very well without any noticeable quality loss due to the bitrate correction for pass 2. I think it's more reliable than repeating the encode with an educated guess for a new --crf.I'll look at it.

[AmigaFuture]

I'm testing with the movie "Say Anything" (1989)..and I'm noticing that with IVTC_SELECTION=1 & SD_PROGRESSIVE=1 set, some of the interlaced extras; Trailers and TV Spots; aren't being rerendered correct because SD_PROGRESSIVE=1 is still set even though IVTC_SELECTION=1 is set but isn't chosen with Right Click. Would you be willing to join IVTC_SELECTION=1 & SD_PROGRESSIVE=1 together? Or, perhaps, make a new option? The 2 options function well for the Deleted/Extended Scenes. I've noticed this for some other BDs as well, like Footloose. Thanks.

I'm using 49.01.

[Lowpro]

2. "Quick-Play" navigation.
When the last menu item is highlighted I'd like to be able to menu down at that point having it wrap back around to the top menu item. Presently it doesn't wrap around. You have to menu up one at a time to get back to the top again.

3. Import/Quick-Play Settings option "Attempt to find original background for BD import/Quick-Play".
I'd love to use the Import/Quick-Play Settings option "Attempt to find original background for BD import/Quick-Play" with several of my titles rather than going with a custom menu background as when testing it utilizes the menu video background from the original disc which is way cool. The only problem is the video doesn't repeat "x" number of times like the original disc does (usually set to play repeatedly several hundred times as seen within BDedit when checking out the retail version of a given disc), so once the video plays once which often fades to black at the end you are then looking at the menu selection items from that point forward against a stark black screen.

Thought I'd chime back in on a couple of enhancement requests I had made a while back. Would really love to see the above two items implemented. I did try to figure out if there was a way I could implement these items myself after the fact by modifying the files in question within the BD folder structure created by BD Rebuilder. No luck there. That being said, I do have an interim solution as far as having the video menu background play more than once, so I thought I'd share what I've been doing. In my case I'm creating "Quick-Play" backups of the TV shows that I own on Blu-ray, then burning to BD-50. Prior to burning to disc I'll determine how much room is going to be left on the disc. I then take a copy of the m2ts file used for the video menu background and join multiple copies of the file together using multiAVCHD, as many as would fit per the remaining space that would be left on the disc with a little breathing room to spare, name the resulting file accordingly and overwrite the original file within my build, then importing the build using BD Rebuilder all over again which in turn accounts for the longer running time of the updated m2ts file. Done deal. End result, I go from a 47 second video menu background for example that plays one time stopping on the last frame (...whatever that may be) to a video menu background that seamlessly loops over and over again (...well, that appears to be looping anyway) for 30 minutes instead just as the retail version of the given disc would do. Of course the retail version of the disc is just having that 47 second video repeat "x" number of times per the particular playlist, usually several hundred times. Short of figuring out how to update the particular playlist myself if that's even possible I've been able to accomplish the same end result while at the same time putting the unused space on my BD-50 to good use. Gotta love it!

[Audiophile1178]

Jdobbs,

Would it be possible to create a feature in BD Rebuilder that would allow the user to tell BD Rebuilder to NOT encode certain VID files?

[DoctorM]

Jdobbs,

Would it be possible to create a feature in BD Rebuilder that would allow the user to tell BD Rebuilder to NOT encode certain VID files?

Do you mean for it to remove those items or to copy that vid untouched?

The former is already present as a hidden option, the later I would like to see as well.

[jdobbs]

I could do that... but there's all kinds of caveats when you allow that kind of thing. A couple that come immediately to mind: 1. Output size can't be guaranteed -- because the parts deselected might violate the size by themselves, or may not leave enough space for what's left. 2. Quality of those actually reencoded can't be guaranteed -- because they get the limited space left over after the deselected parts use their space.

[Audiophile1178]

OK, this is going to be a little lengthy but it should help to understand some of the reasons for this request.

BD Rebuilder is a GREAT program but I FEEL (note that I'm stating my opinion) that it lacks in certain areas when one tries to use CRF values on bonus content and 2-pass on main titles. This would occur in areas such as:

1. Seamless Branching
2. Series discs
3. Films that have bonus content larger than the main title. This is rare but has occurred before.

In all of the above scenarios, BD Rebuilder just can't do these films properly and causes the user to do hours of manual encoding and BDedit manipulation or just accept it and possibly get sub par results on the main title with doing 2-pass on entire disc. I'm by no means a programmer but would LOVE to have this option enabled for the above reasons listed.

To copy that vid untouched?

That is what I meant. It would be great to mark certain VID's so that they don't get encoded and just processed through as if we had the FORCE_NOENCODE=0 enabled only on those VID's.

I could do that... but there's all kinds of caveats when you allow that kind of thing. A couple that come immediately to mind: 1. Output size can't be guaranteed -- because the parts deselected might violate the size by themselves, or may not leave enough space for what's left. 2. Quality of those actually reencoded can't be guaranteed -- because they get the limited space left over after the deselected parts use their space.

I can DEFINITELY see your point and realized that when I asked the question that it can cause novices some problems which is why it would definitely be a hidden option as in all the advanced/experimental options that are available in the hidden options so that it doesn't add complications for the novice user. I'm sure that you must know that many users use this great program that you created in many ways and not just for shrinking movies down to BD25 BD-R's which, if memory serves me correctly, is what you want BD Rebuilder to be. The one stop solution for ALL encoding.

Regarding the scenarios below, many of them would be bigger than a BD25 so the option FORCE_ENCODE=1 would be enabled BUT should be overwritten/ignored when BD Rebuilder comes across a VID flagged with No Encode.

Here are some scenarios that might make this option useful:

1. Somebody wants to do a full backup of a disc and use CRF values ONLY on the extras. This would allow the user to leave the main title untouched to reduce the overall size of the disc but still have the original video quality of the movie while having the extras reduced. When doing this the user would have their output setup as a BD50 but the FORCE_ENCODE=1 would be enabled for the extras to be encoded but not the main title since it was marked with the No Encode option. This would be useful for users that have a Server, HTPC, etc. and playback their material on programs such as XBMC to help conserve space while still having the original picture quality of the main film with the entire disc still intact. This would mean that the disc would most likely be bigger than a BD25 but much smaller than the original BD50 which can be quite useful for all the new titles coming out that seem to contain all 1080p video which can take up quite a big of space. By using CRF values on the extras of those titles I've seen reductions of 80% on those videos while still being quite presentable. This could save the user several GB's or even TB's of data.

2. This would work on all series and seamless branching titles. First, mark the main title/s with no encode and perform a CRF encode on all other VID's. This would, most likely, result in an output bigger than a BD25 disc, in which, the user would have their output setup as a BD50 but the FORCE_ENCODE=1 enabled for the extras to be encoded but not the main title since they were marked with No Encode. This first step shouldn't take too long to perform. Second, take the output of the first step and change BD Rebuilder to output a size of a BD25. Then, mark all the already encoded extras from the first part to No Encode and just encode the main title/s using 2-pass down to a BD25 for your final output. This would allow the highest quality available for the main title/s while still giving the extras a presentable quality. A user could use your wonderful batch processing feature to do many titles at once to help simplify the process.

3. I'm sure there are other scenarios but this is all that I can think of at the moment.


As stated before, I know that I and I'd imagine others would greatly appreciate an implementation of a feature such as this. I'm currently doing some series discs at the moment and would be able to test it out if you like.


As always, THANK YOU FOR YOUR TIME! :)

[jdobbs]

possibly get sub par results on the main title with doing 2-pass That's pretty much the opposite of reality. You will almost always get better results with 2-pass encoding than any other method. The only real advantage of CRF is the time savings related to a single pass. 2-pass will definitely give you better allocation of available bandwidth.

With that said, I'll look at it.

[Sharc]

Personally, I would prefer a method where the user can mark in the Stream Tab which files are to be classified as extras. These are then encoded with the user specified CRF (this feature is already available now). The feature is likely to remain untouched if Quick_CRF is set large enough, say 30. Otherwise it might get recoded fast with slight size reduction and no real quality loss.
But this is only my view, of course.

[DoctorM]

The reason I like the idea is I've found discs that are BD50, but once you strip excessive amounts of lossless non-English audio tracks, trailers, etc., the discs are just a little bit over BD25 sized.
My preference in those cases is to keep the movie untouched, but only re-encoded the extras with whatever it takes to fit it in the space left over. Less encoding is needed, perfect quality for the main title, less for the bits that aren't as important.

[Sharc]

@DoctorM
ok, I see your point. My concern is just if the feature is close to 25MB the extra(s) may get squashed to a non-watchable mash.
(just a quick thought....)

[Audiophile1178]

With that said, I'll look at it.

Thank you very much!

Personally, I would prefer a method where the user can mark in the Stream Tab which files are to be classified as extras. These are then encoded with the user specified CRF (this feature is already available now). The feature is likely to remain untouched if Quick_CRF is set large enough, say 30. Otherwise it might get recoded fast with slight size reduction and no real quality loss.
But this is only my view, of course.

I believe that it would be easier for Jdobbs to program and the user if the opposite was applied. The user marked which file was the main title. Usually, there's only 1 file or a handful of files that would need to be marked as a main title and all else would automatically get considered as bonus. If you think about it, when you have a film that has 40, 100, or possibly more bonus VID's it would be easier for the user to just mark which file/s is the main title rather than going through and marking all 40, 100, or more as the bonus content. After that, BD Rebuilder would automatically know that all the other files are bonus content that should be encoded using whatever CRF value was given but, in reality, either way would get the job done.

[DoctorM]

@DoctorM
ok, I see your point. My concern is just if the feature is close to 25MB the extra(s) may get squashed to a non-watchable mash.
(just a quick thought....)

I'm just thinking back to old DVD Shrink. You could mark any video as compress/blank/copy untouched.

How badly they got compressed when you manually tweaked it was on you, but it was useful.

[Sharc]

I'm just thinking back to old DVD Shrink. You could mark any video as compress/blank/copy untouched.

How badly they got compressed when you manually tweaked it was on you, but it was useful.
Yes, DVD-Shrink, nice to remember ....
One may of course delegate the responsibility of the tweaks to the user. In practice however if a BD-RB encode turns out to be poor the question or complaint will likely end up on the author's desk, I am afraid ;)
Anyway, there are options, but the decision is with jdobbs.

[jdobbs]

Thought I'd chime back in on a couple of enhancement requests I had made a while back. Would really love to see the above two items implemented. I did try to figure out if there was a way I could implement these items myself after the fact by modifying the files in question within the BD folder structure created by BD Rebuilder. No luck there. That being said, I do have an interim solution as far as having the video menu background play more than once, so I thought I'd share what I've been doing. In my case I'm creating "Quick-Play" backups of the TV shows that I own on Blu-ray, then burning to BD-50. Prior to burning to disc I'll determine how much room is going to be left on the disc. I then take a copy of the m2ts file used for the video menu background and join multiple copies of the file together using multiAVCHD, as many as would fit per the remaining space that would be left on the disc with a little breathing room to spare, name the resulting file accordingly and overwrite the original file within my build, then importing the build using BD Rebuilder all over again which in turn accounts for the longer running time of the updated m2ts file. Done deal. End result, I go from a 47 second video menu background for example that plays one time stopping on the last frame (...whatever that may be) to a video menu background that seamlessly loops over and over again (...well, that appears to be looping anyway) for 30 minutes instead just as the retail version of the given disc would do. Of course the retail version of the disc is just having that 47 second video repeat "x" number of times per the particular playlist, usually several hundred times. Short of figuring out how to update the particular playlist myself if that's even possible I've been able to accomplish the same end result while at the same time putting the unused space on my BD-50 to good use. Gotta love it!Ok. I added a hidden item called MENU_ROLLOVER that does the first one. I may even make it the default for the next release, we'll see. I'll look at the second request and see how hard it'll be to implement. I've been meaning to do it, but just haven't gotten around to it.

[Lathe]

Ok. I added a hidden item called MENU_ROLLOVER that does the first one. I may even make it the default for the next release, we'll see. I'll look at the second request and see how hard it'll be to implement. I've been meaning to do it, but just haven't gotten around to it.

Thank you!

I too would like to 'Third' the suggestion about keeping the main title untouched and allowing BDRB to encode all the rest