PDA

View Full Version : Vob blanking functionality


nookzter
24th November 2004, 11:15
Hi,

Ive usually been using Vobblanker before running my DVD files through Rebuilder. I recently started using the "Steal from extras" function and thought it may be handy to be able to select individual VTS sets and blank the one that are not wanted.

By being able to blank VTS sets, would this allow for better quality movies in the processing phase?

Any suggestions or thoughts on including a Vobblanker type function in Rebuilder?

Thanks.

jdobbs
24th November 2004, 12:28
I guess that's not out of the question.

juan0r
24th November 2004, 15:11
Sounds like a good feature. I know I would use it atleast.

Sir Didymus
24th November 2004, 15:35
Originally posted by juan0r
Sounds like a good feature. I know I would use it atleast.

...VERY GOOD FEATURE...
...ME TOO...
:)

mrslacker
24th November 2004, 20:56
I use VobBlanker often and have come to appreciate the complexities in blanking program chains. It seems that no fool-proof process of editing the PGC commands exists, at least not when it comes to killing playback. jsoto (http://forum.doom9.org/showthread.php?s=&postid=571062#post571062) is of that opinion anyway. There doesn't seem to be any problem with blanking while not killing playback. I could live with that in most cases.

It just seems like it might open a can of worms on you, jdobbs. It would be a very useful feature though! I never want to keep previews on my previously owned rental discs, and they're often under the size threshold for reencoding.

That reminds me... I've always wanted an adjustable size threshold. Can that be done with the ini file? Or be made a feature? :D

jdobbs
24th November 2004, 21:55
Originally posted by mrslacker
I use VobBlanker often and have come to appreciate the complexities in blanking program chains. It seems that no fool-proof process of editing the PGC commands exists, at least not when it comes to killing playback. jsoto (http://forum.doom9.org/showthread.php?s=&postid=571062#post571062) is of that opinion anyway. There doesn't seem to be any problem with blanking while not killing playback. I could live with that in most cases.

It just seems like it might open a can of worms on you, jdobbs. It would be a very useful feature though! I never want to keep previews on my previously owned rental discs, and they're often under the size threshold for reencoding.

That reminds me... I've always wanted an adjustable size threshold. Can that be done with the ini file? Or be made a feature? :D Size threshold in what way? Selecting output size, or selecting the size that will/will not be encoded?

nookzter
25th November 2004, 10:23
Im glad a few members agree!! Maybe something to look into before v1.0. :)

Since were talking about blanking VTS then a menu edit tool could also be included. Makes sense to be able to take off extras and any access links to them. THis will definitely make DVD-RB the number one one-click dvd backup...not that it isnt already.

Thanks.

mrslacker
26th November 2004, 02:51
Originally posted by jdobbs
Size threshold in what way? Selecting output size, or selecting the size that will/will not be encoded?

What will/will not be encoded.

(Jetlagged response)

nookzter
26th November 2004, 10:56
@mrslacker

Cant size be controlled using TargetSectors=xxx where xxx is the sector size? This is put into the ini file. I use 2263500 and it always fits onto a DVD-R.

If that doesnt answer your question, sorry, thats how I understood it to be.

cheers

jdobbs
26th November 2004, 12:30
Originally posted by mrslacker
What will/will not be encoded.

(Jetlagged response) I'd recommend using it cautiously but there is a parameter for that called vts_min_size in the [Options] area of the INI. I put it in for debugging. The default is:

vts_min_size=25625

The parameter specifies the number of sectors (2048 bytes each) that defines the point at which a VTS will be either encoded or copied intact. Anything this size or smaller will be simply copied into the output VIDEO_TS directory (it won't be further compressed).

I'd recommend this only be used on those discs that have a lot of VTSs that individually are small, but add up to a lot when combined.

mrslacker
26th November 2004, 17:47
Originally posted by jdobbs
I'd recommend using it cautiously but there is a parameter for that called vts_min_size in the [Options] area of the INI. I put it in for debugging. The default is:

vts_min_size=25625
...
I'd recommend this only be used on those discs that have a lot of VTSs that individually are small, but add up to a lot when combined.

Agreed. I had a disc with at least 20 little extras. There were some music videos and little directors specials. Thanks for the info.

@nookzter
that's (http://forum.doom9.org/showthread.php?s=&postid=532188#post532188) at different topic. ;) No sweat.

CoNS
1st December 2004, 21:19
Originally posted by nookzter
Cant size be controlled using TargetSectors=xxx where xxx is the sector size? This is put into the ini file. I use 2263500 and it always fits onto a DVD-R.I tried to follow your advice and set the TargetSectors parameter to 226350. However, the output was around 5 mb too large for a DVDR.

So I think the various numbers mentioned in this thread (http://forum.doom9.org/showthread.php?s=&postid=532188) are safer to use. The default size in DVD-RB is 2236400 sectors. But it looks like other users have had success with setting the parameter to 2260000 and even 2260448 sectors. But not as high as you suggest.

Does the actual output size from DVD-RB depend on how many passes you set when using CCE?

mrslacker
1st December 2004, 21:53
Originally posted by CoNS
Does the actual output size from DVD-RB depend on how many passes you set when using CCE?

If CCE is doing its job, no. The average bitrate remains the same no matter how many passes are done. The allocation of bitrate will be better as passes are added. There might be VERY slight differences due to stream overhead differences though.

CoNS
2nd December 2004, 16:54
After testing it I can now confirm that it's safe to set the TargetSectors parameter to 2260448, whereas 226350 is too high.

So the max number must be somewhere in between, and probably closer to the first mentioned number.

mrslacker
2nd December 2004, 20:00
The number, 2260448, that I came to was arbitrarily reduced by 7000 sectors. I did that for two reasons: 1. to have a little safety buffer and 2. to save space for any JACKET_P or interactive windows stuff. Trace through my post in the referenced thread and try applying the same process to one of your discs (use the default sectors). You may get different numbers and you might feel more comfortable with a smaller safety buffer.

jdobbs
2nd December 2004, 22:51
Originally posted by CoNS
After testing it I can now confirm that it's safe to set the TargetSectors parameter to 2260448, whereas 226350 is too high.

So the max number must be somewhere in between, and probably closer to the first mentioned number. Be careful. The number is not consistent across all movies... my advice: leave it at the default. All it takes is having to redo one 12 hour encode -- and you'll appreciate the fact that the extra 100MB you get really doesn't noticably improve your output.

CoNS
3rd December 2004, 08:30
Hehe, yeah well, you may have a point there! :)

But why is it that the number is not consistent across all movies?

Of course the size of the source disc vary from movie to movie, but I thought the TargetSectors parameter sets an exact output size (the files untouched by DVD-RB (menus, small VOBs etc.) + the calculated size of the reencoded files)?

mrslacker
3rd December 2004, 17:00
Originally posted by CoNS
But why is it that the number is not consistent across all movies?

Of course the size of the source disc vary from movie to movie, but I thought the TargetSectors parameter sets an exact output size (the files untouched by DVD-RB (menus, small VOBs etc.) + the calculated size of the reencoded files)?

Good question! I am also curious where the variance is introduced. On occasion, I get a disc that breaks the mold and gets close to capacity. Could it really be CCE not making the ABR as accurately as one would expect? Adding an extra pass would help produce more consistent results in that case. Or could it be that the stream overhead is just unpredictable when the a/v is muxed? Food for thought here! I'm sure someone has the answer though. jdobbs? ;)

jdobbs
4th December 2004, 13:09
The target size in sectors is used to calculate the bitrate that is passed to the encoder. But sometimes the encoder misses the target slightly in one direction or another. Also the overhead has an impact. You'll find that discs that hae a lot of small VTSs have a tendency to be slightly larger after calculation.

One of these days I'll get back to that algorithm and maybe improve it a little.

f@chance
4th December 2004, 13:26
I too have experiemented with the size and since I burn Taiyo Yuden (TY) DVD+R disks on my Plextor burner, I finally have come up with 2261000 that sofar has been good in all my encodes. I believe the +R is also a few MBytes less in capacity than the -R, plus TY blank disks have an excellent error ratio. I used to burn Ritek G04 but tried 100 TYs and will not go back to Ritek there is just simply no comparisson. 226100 produces 4.37 while the default produces 4.32

f@chance
5th December 2004, 14:22
Well what do you know just did a rebuild job with TargetSectors parameter to 226100 and it wouldn't burn on a +R Nero refused to because not enough disk space, but it burned fine on to a -R. Well I guess I will keep a few of -R disks around.

jdobbs
5th December 2004, 15:00
As I said a few posts back... you have to be careful in changing that value. My advice to everyone continues to be: leave it at the default.

f@chance
6th December 2004, 11:02
You are probably right no one will notice the difference between 4.32 and 4.37, it's just the idea from the figures I have 50 Meg more to devote to video quality.

Anyhow thanks for the excellent job on DVD Rebuilder it is magic and I love it. No more originals to the friends and their kids. If they destroy the backup so what do another one.