BD Rebuilder Beta - Bug Reports Only

[Ian1182]

I have run into a strange problem processing the first season of The Good Place. The original disks play without any apparent problems.

All the episodes have a similar issue and I'll explain what I'm seeing for Episode 1 as an example. This episode is just over 26 minutes long (26:15.991). BD Rebuilder ran without any error messages, I then created an ISO file with IMGBURN, burnt that to a rewritable disk and attempted playback. I selected episode 1 and it started to show a color calibration menu for 89 seconds and then the episode started, it then played for a total of 26:15 which meant the last 89 seconds of the episode was truncated. I then looked at the original M2TS file and noticed it was 30 minutes and 15 seconds long. That file comprises of

1 minute and 29 seconds of calibration menu
26 minutes & 15 seconds of episode 1
and the remainder some random clip from The Good Place.

If I use MKVTOOLNIX, select the MPLS file for episode 1 from the original disk and create an MKV that is the correct length of 26:15 starting at an offset of 89 seconds and plays ok.

From what I can see all episodes across the two bluray disks have a similar problem.

The disks seem to have some unusual authoring that BD Rebuilder does not handle correctly. Rather than each episode starting at the beginning of the respective M2TS file, its part way into the file. I have attached the MPLS files from the original disk and the processed files if that helps

[Ian1182]

I have an unusual problem processing "The Good Place" season 1, all 13 episodes across the two disks show similar symptoms. To illustrate I'll explain the problem with episode 1. When played from the original Bluray the episode runs for 26 minutes and 15 seconds, however the M2TS file is 30 minutes and 10 seconds long. The playback starts at 89 seconds into the M2TS file and then runs for 26 mins & 15 secs (i.e. exits at 27:44). The initial 89 seconds of the M2TS contains a color test chart

When processed by BR Rebuilder the video component is encoded for first 26 minutes & 15 seconds (89 seconds of test chart and 24:46 of episode). The audio tracks retain the whole 30:10. If I use MKVTOOLNIX and add the playlist file for episode 1 it handles the offset and creates a MKV file that starts/ends at the correct place.

The original Bluray seems to be authored in a strange manner with an offset prior to playback which BR Rebuilder is not handling correctly. Is there something I can provide to allow you to identify what is causing the problem.

[Lathe]

So, again, if I may please ask...

The X264L-64.exe in the BDRB tools folder is some old .exe from 2016...? And, the internal LAVF frame server runs better with it, right? So, does that mean then, that I should use ANOTHER frame server rather than the internal LAVF as selected in the setup of BDRB, would that be preferred because it uses the most recent or a much more recent iteration of the 264-64 codec?

I'm just trying to understand the difference. Should I use say DirectShow instead when using BDRB due to its using the more current version of x264-64? Is there a difference? Also, when using the CMD Line and I want to call a version of x264-64, which one should I call from the BDRB tools folder, or what specifically would be the difference in using one or the other?

Thanks!

[spotswood]

Hello everyone... using the current v0.61.18. Not sure if this is by design or a bug but, when importing an MKV/MP4 with an EAC3/DD+ or TrueHD/Atmos track, BDRB reencodes the track to AC3. When importing an MKV/MP4 with a DTS-MA or DTS:X track it is left intact. I have "Keep HD Audio" checked in Settings, but not sure if that has anything to do with it. Any help/ideas/suggestions appreciated. Thanks!

It would violate the BD standard if left intact -- that is why it is reencoded. Do a search of this thread, this subject has been discussed before. DD+ is a part of the standard, but player support for DD+ isn't required. DD, on the other hand, must be supported. That means that a BD compliant DD+ stream has to include both DD and DD+ together.

Thanks for your reply and suggestion. I went back and looked at a few posts regarding my question. But don't TrueHD/Atmos tracks include the AC3 core? Why are they being reencoded if the core is included? Does this not follow the standard? I just created an MKV of my disc ANNA which has a 7.1 TrueHD track and AC3 core (leaving both video and audio intact). Imported MKV back into BDRB and it still wants to reencode the track to AC3. Would this scenario not be compliant? Very confused...

I don't think you can import into an MKV without the core being removed or at least separated. Even if the AC3 is kept during import (as a second stream), it wouldn't be compliant because the two audios aren't muxed into a single stream for BD. That's if I remember it correctly.

You remember correctly.
MKV cannot hold an "interleaved" track (if the term is correct)
Mux a thd+ac3 track into a MKV container and the result is two distinct tracks thd and ac3OK, so trying this again w/v0.61.22 now knowing the TrueHD/Atmos track will be reencoded. Problem is the TrueHD/Atmos track is being reencoded to AC3 Mono instead of Multi-Ch as it should, yes? Here's the log:
----------------------
[12:06:09] Importing MKV: 1917_4K_HDR
- Collecting audio/video streams from source...
- Converting audio, Track #2, THD to AC3...
- Building pseudo-BD source structure...
[12:47:02] Video import completed successfully.

The resulting reencode under the Stream tab shows AUD_001 AC3, Mono, English. Something weird is going on here...

[ggtop]

OK, so trying this again w/v0.61.22 now knowing the TrueHD/Atmos track will be reencoded. Problem is the TrueHD/Atmos track is being reencoded to AC3 Mono instead of Multi-Ch as it should, yes? Here's the log:
----------------------
[12:06:09] Importing MKV: 1917_4K_HDR
- Collecting audio/video streams from source...
- Converting audio, Track #2, THD to AC3...
- Building pseudo-BD source structure...
[12:47:02] Video import completed successfully.

The resulting reencode under the Stream tab shows AUD_001 AC3, Mono, English. Something weird is going on here...

I think what gonca menat is that your mkv should have at least 2 audio tracks, because the original THD was splitted into THD only and its AC3 core. You should select the audio track holding the core for conversion.

ggtop

[spotswood]

I think what gonca menat is that your mkv should have at least 2 audio tracks, because the original THD was splitted into THD only and its AC3 core. You should select the audio track holding the core for conversion.

ggtopMy problem is that the THD track is being converted to AC3 Mono rather than AC3 Multi-Ch. Correct me if I'm wrong but I think that is incorrect...

[gonca]

I think what gonca menat is that your mkv should have at least 2 audio tracks, because the original THD was splitted into THD only and its AC3 core. You should select the audio track holding the core for conversion.

ggtop

In a BD the thd and ac3 tracks are "interleaved" into 1 track.
When remuxed to mkv you will get a thd and an ac3 track.
Two audio tracks in the mkv

[MrVideo]

In a BD the thd and ac3 tracks are "interleaved" into 1 track.
When remuxed to mkv you will get a thd and an ac3 track.
Two audio tracks in the mkv
Yes, but the AC3 core shouldn't be mono.

[ggtop]

I suggest you compare the audio characterics of both, the original and your mkv e.g. with MediaInfo and come back with the results.

ggtop

[gonca]

Yes, but the AC3 core shouldn't be mono.

Unless the original core was mono

[spotswood]

In a BD the thd and ac3 tracks are "interleaved" into 1 track.
When remuxed to mkv you will get a thd and an ac3 track.
Two audio tracks in the mkvYes, I understand this. It's not the problem...

Yes, but the AC3 core shouldn't be mono.It's the THD track that is being converted to Mono, not the core track. Log from my post above:

[12:06:09] Importing MKV: 1917_4K_HDR
- Collecting audio/video streams from source...
- Converting audio, Track #2, THD to AC3...
- Building pseudo-BD source structure...
[12:47:02] Video import completed successfully.

Unless the original core was monoIt's not, the core is AC3 Multi-Ch @ 640...

I suggest you compare the audio characterics of both, the original and your mkv e.g. with MediaInfo and come back with the results.

ggtopYou are suggesting I compare the audio characteristics of a mono track to a multi-ch surround track? There is no comparison...

[spotswood]

I looked at the code and it specifically excludes printing that line when in MOVIE-ONLY mode. Now I have to figure out whether I did that for a reason -- or was just goofy that day.

EDIT: I realize now that I used the wrong variable for that check. It should have suppressed the message for ALTERNATE output, not all MOVIE-ONLY encodes. I fixed it for the next release.No problem, and thank you...

[MrVideo]

It's the THD track that is being converted to Mono, not the core track. Log from my post above:

[12:06:09] Importing MKV: 1917_4K_HDR
- Collecting audio/video streams from source...
- Converting audio, Track #2, THD to AC3...
- Building pseudo-BD source structure...
[12:47:02] Video import completed successfully.
You are misunderstanding the log entry. Track #2 on the disc is a THD track and it is being converted to AC3. It should do so by extracting the AC3 core.

Again, use MediaInfo to look at the specs for the the THD audio track.

[spotswood]

You are misunderstanding the log entry. Track #2 on the disc is a THD track and it is being converted to AC3. It should do so by extracting the AC3 core.

Again, use MediaInfo to look at the specs for the the THD audio track.OK, here you go...

MediaInfo pre reencode for my 1080p Anna MKV:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference fra : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 58 min
Bit rate mode : Variable
Bit rate : 33.0 Mb/s
Maximum bit rate : 35.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.663
Stream size : 27.4 GiB (88%)
Language : English
Default : Yes
Forced : No

Audio #1
ID : 2
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Codec ID : A_TRUEHD
Duration : 1 h 58 min
Bit rate mode : Variable
Bit rate : 3 616 kb/s
Maximum bit rate : 6 318 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Stream size : 3.01 GiB (10%)
Language : English
Default : Yes
Forced : No
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Format settings : Dolby Surround EX
Codec ID : A_AC3
Duration : 1 h 58 min
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 545 MiB (2%)
Language : English
Service kind : Complete Main
Default : No
Forced : No

.inf:

[Status]
LABEL=ANNA_1080P
VERSION=v0.61.22
SOURCE_SIZE=31433637888
SOURCE_VIDEO_SIZE=31433637888
TARGET_SIZE=26306674688
REDUCTION=.836895646050652
RESIZE_1080=0
RESIZE_1440=0
AUDIO_TO_KEEP=eng;
KEEP_HD_AUDIO=-1
SUBS_TO_KEEP=eng;
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=0
INSTANCES=4
DGDECNV=-1
DGDECIM=0
FRIMSOURCE=0
FFMS2=0
SSIF_MODE=0
UHD_V3_MODE=-1
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00000]
AUDIO=10
PGS=1
APULLDOWN=0
S1440=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=26306674688
RATE=27310
NSIZE=0
FLINK=0
MLINK=0

Log:

----------------------
[06/05/21] BD Rebuilder v0.61.22
[09:02:14] Source: ANNA_1080P_00000
- Input BD size: 29.27 GB
- Approximate total content: [01:58:59.173]
- Target BD size: 24.50 GB
- Windows Version: 6.2 [9200]
- MOVIE-ONLY mode enabled
- Quality: High Quality (Default), 1-Pass VBR
- Decoding/Frame serving: NVENCC
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[09:02:17] PHASE ONE, Encoding
- [09:02:17] Processing: VID_00000 (1 of 1)
- [09:02:17] Extracting A/V streams [VID_00000]
- [09:03:17] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 171,169 frames
- Bitrate: 27,310 Kbs
- [09:03:17] Reencoding: VID_00000, Pass 1 of 1
- [09:19:26] Video Encode complete
- [09:19:26] Processing audio tracks
- Track 4352 (eng): Keeping original audio
[09:19:26]PHASE ONE complete
[09:19:26]PHASE TWO - Rebuild Started
- [09:19:26] Rebuilding BD file Structure
[09:20:08] - Encode and Rebuild complete
- WORKFILES folder removed.
[09:20:09] JOB: ANNA_1080P finished.


MediaInfo post reencode to HEVC: I've bolded the Audio parts in question...

----------------------
[08:46:17] Importing MKV: ANNA_1080P
- Collecting audio/video streams from source...
- Converting audio, Track #2, THD to AC3...
- Building pseudo-BD source structure...
[08:50:52] Video import completed successfully.

MediaInfo:

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4.1@High
Codec ID : 36
Duration : 1 h 58 min
Bit rate : 25.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.503
Stream size : 20.8 GiB
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
format_identifier : HDMV
Source : 00000.m2ts / 00000.m2ts

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 1 h 58 min
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 1 channel
Channel layout : C
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 545 MiB
Language : English
Service kind : Complete Main
bsid : 8
Dialog Normalization : -31
Dialog Normalization : -31 dB
acmod : 1
lfeon : 0
dialnorm_Average : -31
dialnorm_Average : -31 dB
dialnorm_Minimum : -31
dialnorm_Minimum : -31 dB
dialnorm_Maximum : -31
dialnorm_Maximum : -31 dB
dialnorm_Count : 1
format_identifier : AC-3
SamplingCount_Source : General_Duration
Duration_Source : General_Duration
Source : 00000.m2ts / 00000.m2ts

Misunderstanding? Sure looks like 1 CH Mono to me. Any ideas?

[MrVideo]

To me, you made it sound like the THD portion of the audio stream was being converted. As pointed out, the AC3 core should be extracted without any kind of recoding. You should be able to use eac3to to extract the AC3 core from the THD stream and then look at it with media info.

I would find it extremely strange that only a center channel would be placed in the lossy AC3 core and all of the other 7 channels of stuff placed in the THD objects.

It is unfortunate that mediainfo does not list the core configuration.

[spotswood]

To me, you made it sound like the THD portion of the audio stream was being converted.I made it sound that way because that's exactly what it's doing. - Converting audio, Track #2, THD to AC3... "Converting" NOT "extracting". You asked for MediaInfo info and I gave it to you. It's right there in the MediaInfo in Bold and white. I don't know what else to tell you. Try it yourself and see what you come up with...

As pointed out, the AC3 core should be extracted without any kind of recoding. You should be able to use eac3to to extract the AC3 core from the THD stream and then look at it with media info.Yes it should, but that's not what is happening. And why should I have to do that? Shouldn't BDRB handle the extraction/conversion correctly as needed on it's own?

I would find it extremely strange that only a center channel would be placed in the lossy AC3 core and all of the other 7 channels of stuff placed in the THD objects.Well that's why I'm reporting what I think might be a bug. Like I said, try it yourself. Import a MKV with a THD/Atmos track and see what happens. I'm tired and my brain hurts. Have a good evening everyone...

[MrVideo]

I made it sound that way because that's exactly what it's doing. - Converting audio, Track #2, THD to AC3... "Converting" NOT "extracting". You asked for MediaInfo info and I gave it to you. It's right there in the MediaInfo in Bold and white. I don't know what else to tell you. Try it yourself and see what you come up with...
I see below that I missed a very valuable clue and that this is a MKV file, and not a Blu-ray M2TS. Not sure how I missed that, but I did.
Yes it should, but that's not what is happening. And why should I have to do that? Shouldn't BDRB handle the extraction/conversion correctly as needed on it's own?
With a MKV file, the THD track from a M2TS file has already been split into the THD objects file and the AC3 core file. All BDRB needs to do is pull the core from the MKV file. That may be what it is doing and the wrong choice of words was used. I'm not sure you can do anything with the high def audio component, because what is also needed is the core component. I'll leave that to JD to explain.
Well that's why I'm reporting what I think might be a bug. Like I said, try it yourself. Import a MKV with a THD/Atmos track and see what happens. I'm tired and my brain hurts. Have a good evening everyone...
I do not have the file you are dealing with, so I can't do any testing. Using a different MKV file containing THD audio would not be the same.

You can use the MKV toolset to create a new MKV file with only the AC3 core and see what mediainfo now reports. I know, not your job, but it would help with troubleshooting since I suspect that JD doesn't have that file either.

[tebasuna51]

Of course it is a mistery how a THD Atmos 8 channels can be converted, by ffmpeg I suposse, to an AC3 1 channel.

But, if you want an AC3, for what not select the track 3 of pre reencode mkv?
It is clearly the core of TrueHD track from m2ts's BD.

[ggtop]

Misunderstanding? Sure looks like 1 CH Mono to me. Any ideas?

Hi spotswood,

it seems to me you are still selecting the wrong audio track...
Given the fact that your imported source follows a natural numbering audio #4352 is track 1 (previously borked THD) and #4353 is track 2 (AC3@640) according to your MediaInfo log.

Looking in your .inf file you are selecting track 1:
REBUILD_COMPLETE=1
[00000]
AUDIO=10
PGS=1

What does happen if you select audio track 2 BDRB should show you in the stream window?

I suggest you also disable "remove WORKFILES after rebuild" so that you have the chance to examine the temporary files afterwards. Especially AUD_00000_4352.AVS in this case.

ggtop

EDIT: Just had a look with MediaInfo into a random disc containing a THD stream:

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : MLP FBA AC-3 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 1 h 30 min
Bit rate mode : Variable
Bit rate : 640 kb/s
Maximum bit rate : 5 904 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossless
Stream size : 414 MiB (1%)
Service kind : Complete Main
Number of dynamic objects : 13
Bed channel count : 1 channel
Bed channel configuration : LFE

Looking into yours it seems it is indeed missing the core as gonca wrote due to MKV restrictions.

[spotswood]

Hey guys... jdobbs and I had a little educational conversation and he corrected the error in my ways. Who knew you could use MakeMKV to backup to a folder! Not me! What a dumb a**... (wipes a carton of eggs off face). So please disregard my recent ramblings and I'll say it again, what a dumb a**. Crisis caused by pilot error averted... ;^)

[spotswood]

So just FYI and for those curious as to the source file for my previous posts, attached is the full MediaInfo from my original Anna BD that includes the THD-Atmos/core track in addition to the foreign language tracks.

So what I did originally was rip the movie only straight to MKV, keeping only the THD-Atmos/core English track, which I now know is split into 2 seperate tracks per MKV specs. When attempting to convert the movie to UHD/x265, rather than load the original disc into BDRB, I imported the previous movie only MKV into BDRB. During the import process BDRB wants to extract/convert the THD core track to AC3.

Here's where things got wonky. Since the core was already extracted in the previous rip to MKV, there is no core to extract from the THD track (I'm guessing, but what do I know). BDRB now "converts" the THD track to AC3, but converts it to Mono. That is the big mystery and I'll leave that to you and jdobbs to figure out if you want to.

It's actually moot at this point as instead of trying to import my existing MKV files to convert them to UHD/x265, I'll just start over and load the original disc into BDRB and convert from there. Hope this info helps for those interested in what is happening. Sorry for any confusion and thanks for the help provided...

EDIT: The MediaInfo is too large to include in my post so I uploaded as an attachment. I've included just the audio portion since the whole thing including the video and subs is too big. Sorry 'bout that Chief!

[Lathe]

So just FYI and for those curious as to the source file for my previous posts, attached is the full MediaInfo from my original Anna BD that includes the THD-Atmos/core track in addition to the foreign language tracks.

So what I did originally was rip the movie only straight to MKV, keeping only the THD-Atmos/core English track, which I now know is split into 2 seperate tracks per MKV specs. When attempting to convert the movie to UHD/x265, rather than load the original disc into BDRB, I imported the previous movie only MKV into BDRB. During the import process BDRB wants to extract/convert the THD core track to AC3.

Here's where things got wonky. Since the core was already extracted in the previous rip to MKV, there is no core to extract from the THD track (I'm guessing, but what do I know). BDRB now "converts" the THD track to AC3, but converts it to Mono. That is the big mystery and I'll leave that to you and jdobbs to figure out if you want to.

It's actually moot at this point as instead of trying to import my existing MKV files to convert them to UHD/x265, I'll just start over and load the original disc into BDRB and convert from there. Hope this info helps for those interested in what is happening. Sorry for any confusion and thanks for the help provided...

EDIT: The MediaInfo is too large to include in my post so I uploaded as an attachment. I've included just the audio portion since the whole thing including the video and subs is too big. Sorry 'bout that Chief!

I don't know if this would also help, but what I do any time I have MKV files with a THD audio track (where the core has been removed) I just run it through UsEac3to, choose the TrueHD track and select the THD+Ac3 as the output. That puts the removed core back into the THD track as it was originally. Then I just use TSMuxer to replace the now restored THD track w/core back into the BDMV format, from which BDRB can take it from there.

[spotswood]

I don't know if this would also help, but what I do any time I have MKV files with a THD audio track (where the core has been removed) I just run it through UsEac3to, choose the TrueHD track and select the THD+Ac3 as the output. That puts the removed core back into the THD track as it was originally. Then I just use TSMuxer to replace the now restored THD track w/core back into the BDMV format, from which BDRB can take it from there.This sounded interesting so I gave UsEac3to a try. Didn't give the same results as you describe at first, but after playing around with the settings I got it to work. Now TSMuxer accepts the THD/core track instead of ignoring it without the core. This helps immensely! Thanks for the tip!

[Lowpro]

I'm not sure if I've mentioned this or not. It's related to "Quick-Play" menus that contain multiple pages.

The "PAGE" label and "PREV/NEXT" buttons are positioned too close to the last QP menu item on a given page. Example provided below.

https://www.lowpro.net/bdrb/quick_play/qp_prev_next_before_thumb.jpg (https://www.lowpro.net/bdrb/quick_play/qp_prev_next_before.jpg)

The "PREV/NEXT" buttons actually overlap the last QP menu item on a given page. Well, you can't always tell. It depends on the QP menu item characters involved and "PREV/NEXT" button positioning which is determined by the longest QP menu item naming on the page. Here's a closer look. See below.

https://www.lowpro.net/bdrb/quick_play/qp_prev_next_overlap.jpg

The spacing from QP menu item to QP menu item is excellent. I'd love to see that same spacing used when the given page includes the "PAGE" label and "PREV/NEXT" buttons as well. It would prevent the overlapping as shown above and look much better in general.
__________________________________

And if you'll indulge me since it's related...
In addition to the increased spacing I'd love to see options added so that one could set the positioning of the "PAGE" label and "PREV/NEXT" buttons respectively. The added flexibility would be very welcome. Something like the below perhaps.

MENU_PAGE_LABEL_HORIZONTAL=n (n = 0-1919 - Offset from left of 1080p screen.)
MENU_PAGE_LABEL_VERTICAL=n (n = 0-1079 - Offset from top of 1080p screen.)
MENU_PREV_NEXT_HORIZONTAL=n (n = 0-1919 - Offset from left of 1080p screen.)
MENU_PREV_NEXT_VERTICAL=n (n = 0-1079 - Offset from top of 1080p screen.)

In my case I'd left justify the "PAGE" label with the QP menu items and position the "PREV/NEXT" buttons, so that the same amount of menu backdrop is to the right of those buttons as is to the left of the "PAGE" label. This would remain consistent from page to page. (My menu backdrop is part of the menu background image in this case as I prefer the menu backdrop to have a fixed width from page to page.) I'd also bottom align the "PAGE" label with the "PREV/NEXT" buttons so that the "PAGE" label was not crowding the last QP menu item.

And below is what the end result would look like which includes the increased spacing after the last QP menu item.

https://www.lowpro.net/bdrb/quick_play/qp_prev_next_page_thumb.jpg (https://www.lowpro.net/bdrb/quick_play/qp_prev_next_page.jpg)

Now tell me that doesn't rock. Symmetry is a beautiful thing. It can make all the difference in the world. The above looks far better than the first image I posted in my reply here. Would love to see BD Rebuilder improved in this regard.

[jdobbs]

@Lowpro

I'll take a look at it.

[Lowpro]

@Lowpro
I'll take a look at it.
Excellent. And so you know, the thought hadn't occured to me that I could reposition the "PREV/NEXT" buttons using BDedit. For each QP menu item, including the "PREV/NEXT" buttons you can change the "X" and "Y" values. Works like a charm. The only thing I haven't figured out yet is how to reposition the "Page" label. Well I assume it's a label as it's not listed as a button in BDedit anyway. If it were I could just reposition it how I like and call it a day.

As for the current spacing, from BDedit I can see that the "Y" value increases by 50 from QP menu item to QP menu item. The "Y" value from the last QP menu item to the "PREV/NEXT" buttons only increases by 40 however, hence the "PREV/NEXT" buttons overlapping the last QP menu item. See below taking note of the "Y" value from button to button.

https://www.lowpro.net/bdrb/quick_play/qp_spacing_bdedit_01.jpg

https://www.lowpro.net/bdrb/quick_play/qp_spacing_bdedit_02.jpg

https://www.lowpro.net/bdrb/quick_play/qp_spacing_bdedit_03.jpg

And here's what the end result looks like when the same spacing is used, i.e. increasing the "Y" values for the "PREV/NEXT" buttons by 10. Much better wouldn't you say. (Using TotalMedia Theatre 3 on an old Windows XP desktop to take screenshots of the actually Blu-ray menus. Comes in handy.)

Before:
https://www.lowpro.net/bdrb/quick_play/qp_prev_next_before_thumb.jpg (https://www.lowpro.net/bdrb/quick_play/qp_prev_next_before.jpg)

After:
https://www.lowpro.net/bdrb/quick_play/qp_prev_next_after_thumb.jpg (https://www.lowpro.net/bdrb/quick_play/qp_prev_next_after.jpg)

So for now I can certainly just increase the "Y" value of the "PREV/NEXT" buttons by 10 using BDedit. Also loving the fact I can slide the "PREV/NEXT" buttons down further to the right now like I want. Just wish I could figure out how to reposition the "PAGE" label. I don't see how that can be done in BDedit unfortunately. I see no reference to the "PAGE" label in BDedit at all. Well, unless I just don't know where to look.

Measuring things out in Photoshop I'd have to increase the "Y" value of the "PAGE" label by 16. The "PAGE" label would then be bottom aligned with the "PREV/NEXT" buttons no longer crowding the last QP menu item as a result. To align the "PAGE" label with the other QP menu items I'd need to increase the "X" value by 38. End result shown below. (I increased the "X" values of the "PREV/NEXT" buttons by 230 as well just for fun. Couldn't help myself. Loving the ability to reposition those buttons now. I updated all my QP menus for this TV series actually. To check out the whole spread see here (https://forum.blu-ray.com/showthread.php?p=19023565#post19023565).)

https://www.lowpro.net/bdrb/quick_play/qp_prev_next_page_thumb.jpg (https://www.lowpro.net/bdrb/quick_play/qp_prev_next_page.jpg)

The above would be much better positioning for the "PAGE" label I think. Perhaps you'll consider having the "PAGE" label use that positioning per a future build of BD Rebuilder. It would be an excellent improvement as would increasing the spacing between the last QP menu item and "PREV/NEXT" buttons of course. Better yet, the addition of hidden options for setting the horizontal and vertical positioning of the "PAGE" label and "PREV/NEXT" buttons. Okay, I better quit while I'm ahead. :-P In any event, I appreciate you having a look. Thanks!

[jdobbs]

As for the current spacing, from BDedit I can see that the "Y" value increases by 50 from QP menu item to QP menu item. The "Y" value from the last QP menu item to the "PREV/NEXT" buttons only increases by 40 however, hence the "PREV/NEXT" buttons overlapping the last QP menu item. See below taking note of the "Y" value from button to button.Just note that the amount the Y value increases is dependent upon the font size selected and the number of menu items. But, I think, 50 is the default.

If I remember correctly, the PREV/NEXT buttons are positioned based upon the BACKDROP. I'm guessing that the backdrop in your menus are created as a part of the background image? I guess I could also add an option to force the height/width of the backdrop.

That whole quick menu feature was a lot of work... it's good to see that someone is getting some use out of it.

[Lowpro]

Just note that the amount the Y value increases is dependent upon the font size selected and the number of menu items. But, I think, 50 is the default.Are you sure about selection of the font size? I'm not seeing that as an option. Measuring in Photoshop it looks to be a 20pt font. It's the perfect size I think. I've never felt the need to change it anyway.

If I remember correctly, the PREV/NEXT buttons are positioned based upon the BACKDROP. I'm guessing that the backdrop in your menus are created as a part of the background image? I guess I could also add an option to force the height/width of the backdrop.That's what I've observed. The "PAGE" label and "PREV/NEXT" buttons are positioned based upon the BACKDROP. And yes, I'm not using the BACKDROP. I have it set to be fully transparent. Instead I'm including the backdrop as part of the background image that way I can determine the width and height myself, including how much padding I'd like around the QP menu items. (See below.) My preference is to have the width of the backdrop remain the same from page to page, the height still changing based on the number of QP menu items on the given page. I'm using a unique background image per page.

http://www.lowpro.net/bdrb/quick_play_menu_photoshop_thumb.jpg (http://www.lowpro.net/bdrb/quick_play_menu_photoshop.jpg)

With "The Andy Griffith Show" my backdrops are actually the same width across all 8 seasons, page to page, season to season. (See above.) It makes for much faster work when creating so many menu backgrounds. More importantly, I like the uniformity. In this case I determined the width of the backdrop based on the longest QP menu item across all 8 seasons. I then set the width of the backdrop so that it extends out 96 pixels or so past the extents of that QP menu item on each side. That's then the backdrop width I used across the entire TV series. (Click here (https://forum.blu-ray.com/showthread.php?p=19023565#post19023565) to view the Blu-ray menus for all 8 seasons.)

I guess I could also add an option to force the height/width of the backdrop.An option to independently force the height and width of the BACKDROP would be excellent. I'm not sure that would be enough for me to start using the actual BACKDROP again though as I'd no longer be able to control the precise placement of the QP menu items on the BACKDROP. By making the BACKDROP fully transparent I'm able to position just the QP menu items basically. I include the backdrop within my background image which allows for setting the precise height, width and position of the backdrop. I then position the QP menu item selection area using "MENU_HORIZONTAL" and "MENU_VERTICAL", so that the QP menu items fall precisely where I'd like them to on my background image (with included backdrop).

That whole quick menu feature was a lot of work... it's good to see that someone is getting some use out of it.I can only imagine how much work was involved and yes, I'm getting a ton of use out of the feature. It's actually the only thing I use BD Rebuilder for. Well, I do occassionally create a Movie-Only Backup of a given Blu-ray. Most of the time I use Clown_BD to do that though. For everything else aside from Blu-ray menu creation I use multiAVCHD. That being said, for all of my QP menus I'm using BDedit to customize the QP menu item and page navigation behavior anyway. As such, it's not a big deal to adjust the "X" and "Y" coordinates for the "PREV" and "NEXT" buttons myself. Again, it didn't occur to me I could just change the button positioning using BDedt. Setting the vertical spacing between the last QP menu item and the "PREV/NEXT" buttons from 40 to 50 would still be a welcome change though.

And perhaps you can shed some light on this for me. The "PAGE" label is still eluding me. Well, I'm calling it a label. It doesn't appear to be a button and isn't present in BDedit that I can see. I'd love to be able to control the placement. I'd be curious to know how that's being implemented. The "PAGE" label would look so much better if it were lined up with the other QP menu items and bottom aligned with the "PREV/NEXT" buttons per the mock-up in my previous post. An option to hide the "PAGE" label or make it fully transparent would even suffice. I could then just include the "PAGE" label within my backgroud image instead.

[Lowpro]

He shoots! He scores! I just came up with a workaround, so that I can reposition the "PAGE" label for my QP menus. My goal was to reposition the "PAGE" label, so that it was aligned with the other QP menu items and bottom aligned with the "PREV/NEXT" buttons as shown in the mock-up I posted a couple replies back. So as I mentioned previously, I wasn't seeing a way this could be done from BDedit. For whatever reason it just hit me. The "PAGE" label is actually part of the QP menu item selection area. That I can control the positioning of via BDRB. I can also set the position of each QP menu item using BDedit, hence my workaround. (In my case I set BD Rebuilder's backdrop to be fully transparent. I then include a backdrop within my background image instead.)

Tried it just now. It works beautifully. Once creating the QP menu initially I load the BDMV folder up in BDedit making all my updates as I normally do. This now includes adjusting the positioning of the "PREV" and "NEXT" buttons before remuxing the "99002 & 99004" M2TS files (...the QP menu items). At this point my QP menu is set to go with the exception of the "PAGE" label. To reposition the "PAGE" label I recreate the QP menu shifting the QP menu item selection area to the right by 38 and down by 16, i.e. the BDREBUILDER.INI hidden options, "MENU_HORIZONTAL" and "MENU_VERTICAL". I then copy the "99001 & 99003" M2TS and CLPI files (...the QP menu item selection area) from the resulting QP menu overwriting the same files from my original QP menu. Easy peasy lemon squeezy. Gotta love it!

[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.

[Lowpro]

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]

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]

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]

@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]

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]

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]

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]

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]

Are you referring to binary/decimal or GB/MB?
GB/MB, as seen in the original post regarding this.

[jdobbs]

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]

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]

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]

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]

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,624Wrong. 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.