PDA

View Full Version : BD-RB 'injecting' files into the project


turbojet
27th February 2009, 14:48
I found a temporary workaround (until BD-RB is fixed) for the undersize issue but it takes almost twice as long. What I do is:
- full encode with BD-RB using quick extras but don't let it rebuild
- load avs, audio, all the subs kept extracted from BD-RB into RipBot264 (it only supports 1 audio track currently)
- subtract the size of the encoded m2ts files except for movie m2ts from intended media and insert this into RipBot264 target size.
- set output to blu-ray in RipBot264 and encode, it gives you the bitrate to use if you want to use x264 directly or another frontend
- rename the m2ts to BD-RB format such as VID_00011.AVS.264
- then resume in BD-RB to copy all the needed files and m2ts into another folder. (You could probably mux to m2ts and replace the rebuilt m2ts with the more accurately sized one)

I've done this on a few so far and they've been within 5 MB of my intended media usage.

However I've tried cancelling BD-RB when its encoding main movie video and then 'injecting' the video into the project but when resuming it goes to encode the main movie. So I have to encode the movie twice which takes a long time but it sometimes earns me 400-500 MB that otherwise wasn't used for BD9 output and I'd imagine much more for BD25 output. Does jdobbs or anyone else know a way to workaround the problem of resuming after injecting?

edit: If I could enter in a bitrate for the main movie in BD-RB, maybe with M2TS_TARGET in BDREBUILDER.inf but I'm not sure what this number means. I know DVDRB uses sector sizes and it usually gets within 10 MB of what you set which is plenty good.

jdobbs
27th February 2009, 15:00
Undersize issue???

C'mon. If there's an issue let's fix it, not dance around it! Are you talking significant undersize?

turbojet
27th February 2009, 15:05
Yes there is a sizing issue which a lot of people have posted about. The most I can remember seeing is around 600 MB which is quite signifigant with DVD9 and even more so with DVD5 output, I wouldn't even care with BD25 output. It seems to undersize a lot more with more audio and subs kept.

Right now I'm doing a 129 minute movie with 300 MB of encoded extras resized to 720p, 1 ac3 stream, 7 sup's intended for a DVD5.

RipBot264 calculated 3134 kbps with a target size of 4170MB which I already encoded and it turned out to be 4164 MB + 300 MB of extras = 4464 MB

BD-RB is using 2333 kbps (confirmed with LAST_CMD.txt too) with TARGET_SIZE=4600 which according to RipBot264 will equal a 3338 MB m2ts so a final output of 3638 MB which is a far cry from 4600 MB.

Edit: BD-RB output was 2329 kbps, 3333 MB m2ts. There's 2x50 MB files in the JAR directories and there was a 761 MB video only m2ts that was directly copied. I'll check and see what it is when I get home. The total output was 4561 MB so 39 MB undersize which is definitely tolerable. I will look at the other ones I did that were much further off and report the results.

Furiousflea
27th February 2009, 15:17
I found a temporary workaround (until BD-RB is fixed) for the undersize issue but it takes almost twice as long. What I do is:
- full encode with BD-RB using quick extras but don't let it rebuild
- load avs, audio, all the subs kept extracted from BD-RB into RipBot264 (it only supports 1 audio track currently)
- subtract the size of the encoded m2ts files except for movie m2ts from intended media and insert this into RipBot264 target size.
- set output to blu-ray in RipBot264 and encode, it gives you the bitrate to use if you want to use x264 directly or another frontend
- rename the m2ts to BD-RB format such as VID_00011.AVS.264
- then resume in BD-RB to copy all the needed files and m2ts into another folder. (You could probably mux to m2ts and replace the rebuilt m2ts with the more accurately sized one)

I've done this on a few so far and they've been within 5 MB of my intended media usage.

However I've tried cancelling BD-RB when its encoding main movie video and then 'injecting' the video into the project but when resuming it goes to encode the main movie. So I have to encode the movie twice which takes a long time but it sometimes earns me 400-500 MB that otherwise wasn't used for BD9 output and I'd imagine much more for BD25 output. Does jdobbs or anyone else know a way to workaround the problem of resuming after injecting?

edit: If I could enter in a bitrate for the main movie in BD-RB, maybe with M2TS_TARGET in BDREBUILDER.inf but I'm not sure what this number means. I know DVDRB uses sector sizes and it usually gets within 10 MB of what you set which is plenty good.

I've said already a few times, all I do is just set the target size in the ini ABOVE the standard by a couple hundred mb for DVD9. I find setting it to 8220-8250 for movie only gives an output of about 7.87-7.91GB.

This is good enough especially when burning to cheap media.

For BD25 (just got a burner today) I will be setting it at 23500

turbojet
27th February 2009, 15:24
FuriousFlea I saw that and tried your suggestions but depending on the length of the movie, whether its AC3 or DTS and how many subs I kept it will still undersize signifigantly.

turbojet
27th February 2009, 15:45
Jdobbs: checking bitrate against RipBot264 I think would be the easiest way to check things. Ever since atak and I worked out the DTS overhead, I only tested for him, it's been within 10 MB of accuracy for me on about 40 different movies and I see very few posts about inaccurate size in the thread. I'm willing to test for you just give me a shout.

jdobbs
27th February 2009, 17:30
I personally haven't seen any undersizing even close to what you're discussing. I'm also not one of those people who are more interested in output size than in quality. I figure that BD-RB stays withing a couple of percent of the target value (under) -- that's good enough. So far it has. If it looks like it is consistently going under, I'll adjust the muxing constant up a little.

If you can identify what might be happening in your case, I'll look into it. But you're opening up a real can of worms when you decide to "encode and replace" on a full disc backup. It doesn't work like that.

Furiousflea
27th February 2009, 18:40
I personally haven't seen any undersizing even close to what you're discussing. I'm also not one of those people who are more interested in output size than in quality. I figure that BD-RB stays withing a couple of percent of the target value (under) -- that's good enough. So far it has. If it looks like it is consistently going under, I'll adjust the muxing constant up a little.

If you can identify what might be happening in your case, I'll look into it. But you're opening up a real can of worms when you decide to "encode and replace" on a full disc backup. It doesn't work like that.

This is the key, if there was no consistency I'd completely see your point. From my experience it is very consistent. In my situation I don't have undersizing of 600mb because I change the target bitrate to a minimum of 8140mb for DVD9. If I stuck with your conservative value I'd be getting around 600mb. The points here are that...

1. There is consitency.

2. The bitrate set in the ini is never achived by a good 200-300mb.

So you can have your cake and eat it so to speak jdobbs. Either make it so that when someone sets it to DVD9 output size it uses the value of 8140 (which still undersizes by at least 100mb...more but for argument's sake). Or make the 7910 actually mean that. Because I can promise you setting it to 7910 nowhere near fills a DVD9. About 7.4-7.5GB every time.

I can see things might go a bit awry when there are loads of extras and audio tracks on the disc your 7910 becomes more accurate, but who on earth would put be encoding discs like that and placing the output on DVD9.

Not a big deal but it's more than 100-150mb as you are implying. :)

Furiousflea
27th February 2009, 18:46
I personally haven't seen any undersizing even close to what you're discussing. I'm also not one of those people who are more interested in output size than in quality. I figure that BD-RB stays withing a couple of percent of the target value (under) -- that's good enough. So far it has. If it looks like it is consistently going under, I'll adjust the muxing constant up a little.

If you can identify what might be happening in your case, I'll look into it. But you're opening up a real can of worms when you decide to "encode and replace" on a full disc backup. It doesn't work like that.

I think everyone is reading from the same page, it's just that it isn't hitting it by a couple of % - 160mb, call it 200mb. Definately fine and a good idea with cheap media being how it is and crappy layer break transitions.

jdobbs
27th February 2009, 20:00
This is the key, if there was no consistency I'd completely see your point. From my experience it is very consistent. In my situation I don't have undersizing of 600mb because I change the target bitrate to a minimum of 8140mb for DVD9. If I stuck with your conservative value I'd be getting around 600mb. The points here are that...

1. There is consitency.

2. The bitrate set in the ini is never achived by a good 200-300mb.

So you can have your cake and eat it so to speak jdobbs. Either make it so that when someone sets it to DVD9 output size it uses the value of 8140 (which still undersizes by at least 100mb...more but for argument's sake). Or make the 7910 actually mean that. Because I can promise you setting it to 7910 nowhere near fills a DVD9. About 7.4-7.5GB every time.

I can see things might go a bit awry when there are loads of extras and audio tracks on the disc your 7910 becomes more accurate, but who on earth would put be encoding discs like that and placing the output on DVD9.

Not a big deal but it's more than 100-150mb as you are implying. :) I fixed something related to sizing not very long ago... I'm trying to remember if it is in v0.19.06 or the one I'm working on now (v0.20.1) -- I'll have to look.

What I meant by consistency is: it does the same thing for everybody... if I adjusted it to pick up the 600MB you report, my encoding (and most other people's) would all be oversized. I just went through a group of BD-5s and BD-9s I have on my hard drive... and I can't find any that deviate from the target more than about 150MB (on DVD-9). Are you doing anything unusual (preprocessing etc) before running it through BD-RB?

Furiousflea
27th February 2009, 20:17
I fixed something related to sizing not very long ago... I'm trying to remember if it is in v0.19.06 or the one I'm working on now (v0.20.1) -- I'll have to look.

What I meant by consistency is: it does the same thing for everybody... if I adjusted it to pick up the 600MB you report, my encoding (and most other people's) would all be oversized. I just went through a group of BD-5s and BD-9s I have on my hard drive... and I can't find any that deviate from the target more than about 150MB (on DVD-9). Are you doing anything unusual (preprocessing etc) before running it through BD-RB?

I see, then you're doing the right thing (lol that sounds so patronising). I gotcha though, like you say if everyone isn't getting it then it's not really anything you can do and prolly down to the user to have a play with different numbers - I guess that's why the settings there. Also it's early days and not a bug as such.

turbojet
28th February 2009, 09:20
1080p 103 minute movie, 1536 DTS, 2 sups, 433 MB extras, target size 8150 MB. Turned out to be 7931 MB which is about 3% from the target size, not bad but in this case I would still inject the file back in to get within 1% of size, I think with not much effort could nail it 8140-8150 MB.
I understand wanting to play it safe and not oversize but isn't that why the default target sizes are a little less than the capacity?
I know when I set DVD-RB to output a certain size it gets within 1% of that and always has from what I can remember, it would be nice to see the same behavior from BD-RB eventually. I can understand size isn't top priority but I don't think it should be forgotten either.

If it helps I will keep giving undersized reports here.

turbojet
1st March 2009, 08:59
Full backup using quick extras encode at CRF 28 unless otherwise noted.
size outside of parenthesis is v0.19.07 about 2.0-3.5% off
() is v0.20.01 about 0.5-2.0% off
[] is v0.20.03
| is used to separate 4480 and 8150 target size

103 minutes, 1 DTS, 2 sups, 551 MB extras/menus = 4441 MB (4507 MB) [4508 MB] | 7931 (8054 MB)
107 minutes, 1 DTS, 5 sups, movie only = 4437 MB
110 minutes, 1 AC3, 6 sups (1 is forced), 307 MB extras/menus = 4358 MB (4410 MB) [4422 MB] | 7846 MB (7954 MB) [7966 MB]
110 minutes, 1 AC3, 6 sups (1 is forced), movie only = 4344 MB
116 minutes, 1 AC3, 4 sups, 500 MB of extras = (7978 MB)
116 minutes, 1 AC3, 4 sups, movie only = (4426 MB)
117 minutes, 1 AC3, 5 sups, 979 MB extras/menus = 4417 MB (4473 MB) | 7893 MB (8039 MB)
117 minutes, 1 AC3, 5 sups, movie only = (4434 MB)
139 minutes, 1 AC3, 7 sups, 1128 MB extras/menus = 4565 MB (4500 MB) | 7975 MB (8033 MB)
140 minutes, 1 AC3, 7 sups, 1655 MB extras/menus = 7943 MB (8043 MB)
140 minutes, 1 AC3, 7 sups, movie only = 4374 MB (4442 MB)

Furiousflea
1st March 2009, 11:51
Dark Knight Bonus Disc - Target 7910 (default) - Output - 7.45GB - :eek:

deank
1st March 2009, 11:57
:) Well 7,45gb is 7630 which is about 3.5% difference from the target :)

k-c-ksum
1st March 2009, 12:25
100meg under size if fine imo, burning rite to the edge is asking for trouble. I find that the outer few mill of blank media is were a disc can fail over time so always try to avoid squeezing to much data on them

Furiousflea
1st March 2009, 12:48
:) Well 7,45gb is 7630 which is about 3.5% difference from the target :)

Well that's all cool then if that's acceptable to the dobbs meister :)

turbojet
1st March 2009, 12:58
k-c-ksum I understand that and by default BD-RB is set to use a lower file size, however it usually ends up at least 2-3% lower then its target but some times larger then it's target. A quick fix for advanced users is the ability to inject a file which is what I'm asking for without encoding the movie twice it would be nice to do at least until BD-RB sizing issues are fixed.