BD Rebuilder Beta - Bug Reports Only

[Lowpro]

Originally Posted by MrVideo

BDRB should be able to all that for you instead. Having to use BDEdit is overkill. JD said that he is looking into it.

I use BDedit to customize my Blu-ray menus in a number of ways. It's not overkill to take one extra minute while I'm in BDedit anyway to reposition a few menu buttons. I enjoy using the application and don't expect BDRB to check every box for me. If JD updates BDRB in some way that results in me spending less time in BDedit that's great. If not, I'm still able to produce the end result I'm looking for now. That's the exact attitude I'm imagine JD welcomes with respects to his application and those that use it.

[MrVideo]

Off topic, a little bit.. @Lowpro, what software did you use to get the screen grabs of the complete menus?

[Lowpro]

Originally Posted by MrVideo

Off topic, a little bit.. @Lowpro, what software did you use to get the screen grabs of the complete menus?

I use TotalMedia Theatre 3. I've got an old Windows XP desktop that still has it installed. Comes in handy.

[MrVideo]

Originally Posted by Lowpro

I use TotalMedia Theatre 3. I've got an old Windows XP desktop that still has it installed. Comes in handy.

I kinda figured it was something like that. Thanks for the info.

[MrVideo]

@JD: Here's one for ya... the main video of a UHD disc is 93.78GB. The target is a 25B disc. After re-encoding, that video is 70.23GB. Not exactly the right size to fit on a 25B disc. There were zero errors in the log. All went as it was supposed to, except that the wrong size was the result. This one might be a little tough to figure out when there are zero errors that can be used as hints.

[jdobbs]

Originally Posted by MrVideo

@JD: Here's one for ya... the main video of a UHD disc is 93.78GB. The target is a 25B disc. After re-encoding, that video is 70.23GB. Not exactly the right size to fit on a 25B disc. There were zero errors in the log. All went as it was supposed to, except that the wrong size was the result. This one might be a little tough to figure out when there are zero errors that can be used as hints.

Can you post your settings? That way I can try them on a similar disc. Maybe I will able to repeat it.

[MrVideo]

OK, here is BDREBUIKDER.INI:

[Options]
VERSION=0.61.0.22
ENCODER=1
MODE=0
ENCODE_QUALITY=0
ONEPASS_ENCODING=2
AUTO_QUALITY=1
NVENC_CAPABLE=1
TARGET_SIZE=23500
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=0
SD_TO_1080=0
IGNORE_3D=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=1
AUDIO_DRC=0
DECODER=0
AVCHD=1
REMOVE_WORKFILES=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
PGSTOSRT=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=23500
[Paths]
WORKING_PATH=F:\BD-REBUILDER\WORK\
SOURCE_PATH=E:\

What I find a little interesting is that "CUSTOM_TARGET_SIZE=23500" does not equal what the log reports as the target size: 22.95 GB.

[gonca]

Originally Posted by MrVideo

What I find a little interesting is that "CUSTOM_TARGET_SIZE=23500" does not equal what the log reports as the target size: 22.95 GB.

22.95GB x 1024= 23500MB

I think that Jd uses the normal binary conventions

[MrVideo]

You would think that you would use one method over the other, but not both. Makes for a little confusion.

[jdobbs]

Originally Posted by MrVideo

You would think that you would use one method over the other, but not both. Makes for a little confusion.

There is only one. Computers don't care how many fingers there are on two hands. They exist in a binary world.

[MrVideo]

Originally Posted by jdobbs

There is only one. Computers don't care how many fingers there are on two hands. They exist in a binary world.

Right, but in one place you use the left hand and in another you use the right. Why not use the same counting system in both places?

[gonca]

Originally Posted by MrVideo

Right, but in one place you use the left hand and in another you use the right. Why not use the same counting system in both places?

Are you referring to binary/decimal or GB/MB?

[MrVideo]

Originally Posted by gonca

Are you referring to binary/decimal or GB/MB?

GB/MB, as seen in the original post regarding this.

[jdobbs]

Originally Posted by MrVideo

GB/MB, as seen in the original post regarding this.

So you're saying you don't like the fact that one is in GB and the other is in MB?

Those are both the same counting system.

That's like saying "In one place you say '.5 million' and in the other you say '500 thousand'. Which is it?"

[cartman0208]

I'd guess the "better" human readable format would be in GB in this case, as in the logs.
For the config you would definetely use something without punctuation ... which gets us to MB

[jdobbs]

Originally Posted by cartman0208

I'd guess the "better" human readable format would be in GB in this case, as in the logs.
For the config you would definetely use something without punctuation ... which gets us to MB

Yeah. If, when reading it, you use GB you then have to account for whether a certain country uses a "," or "." (or others) as the decimal separator.

[MrVideo]

Originally Posted by jdobbs

Yeah. If, when reading it, you use GB you then have to account for whether a certain country uses a "," or "." (or others) as the decimal separator.

The log does use the "." as the separator. The point is that if you add the "." to 23500, you get 23.5 GB. But, the log says 22.95 GB. As gonca points out, one value is 1000 based while the other is 1024 based. What I am requesting is that the same base be used in both locations. Or at least use/add the correct terminology for what is being used:

Kilobyte (KB)	1000¹ = 1,000
Megabyte (MB)	1000² = 1,000,000
Gigabyte (GB)	1000³ = 1,000,000,000
Terabyte (TB)	1000⁴ = 1,000,000,000,000
Petabyte (PB)	1000⁵ = 1,000,000,000,000,000
 	 
Kibibyte (KiB)	1024¹ = 1,024
Mebibyte (MiB)	1024² = 1,048,576
Gibibyte (GiB)	1024³ = 1,073,741,824
Tebibyte (TiB)	1024⁴ = 1,099,511,627,776
Pebibyte (PiB)	1024⁵ = 1,125,899,906,842,624

[gonca]

Originally Posted by MrVideo

As gonca points out, one value is 1000 based while the other is 1024 based.[/code]

Not quite.
Both values are based on 1024 (binary system).
Just the GB and MB differ

Never pointed out that one value is 1000 based while other is 1024 based. Would make absolutely no sense to do that.
I also mentioned that Jd prefers the binary (1024) convention

In binary 1024 MB does equal 1 GB
Kilo/Mega/Giga etc was originally binary
Somewhere along the way it was altered to be decimal (HDD manufacturers might have had something to do with it)
and this silly Gibi/Kibi stuff was introduced

Yeah, I prefer the binary convention myself

[gonca]

@Jdobbs
Welcome to the rabbit hole.

[jdobbs]

Originally Posted by MrVideo

The log does use the "." as the separator. The point is that if you add the "." to 23500, you get 23.5 GB. But, the log says 22.95 GB. As gonca points out, one value is 1000 based while the other is 1024 based. What I am requesting is that the same base be used in both locations. Or at least use/add the correct terminology for what is being used:

Kilobyte (KB)	1000¹ = 1,000
Megabyte (MB)	1000² = 1,000,000
Gigabyte (GB)	1000³ = 1,000,000,000
Terabyte (TB)	1000⁴ = 1,000,000,000,000
Petabyte (PB)	1000⁵ = 1,000,000,000,000,000
 	 
Kibibyte (KiB)	1024¹ = 1,024
Mebibyte (MiB)	1024² = 1,048,576
Gibibyte (GiB)	1024³ = 1,073,741,824
Tebibyte (TiB)	1024⁴ = 1,099,511,627,776
Pebibyte (PiB)	1024⁵ = 1,125,899,906,842,624

Wrong. And the "Kibi" bullshit is nonsense made up by people who know nothing. I've been doing this for over 40 years (and have taught computer science at the collegiate level) -- and a Kilobyte has always been 1024, and in the real world it always will be, no matter what some new-age "I can't comprehend binary" limp-dick says.

Period.