BD Rebuilder Beta - Bug Reports Only

[Weirdo]

This BD disc fails on CRF mode. Automatic Quality (2-pass) completed fine. Also did a very quick test on ABR mode, it seemed to work fine. Logs here.

[jdobbs]

Originally Posted by Weirdo

This BD disc fails on CRF mode. Automatic Quality (2-pass) completed fine. Also did a very quick test on ABR mode, it seemed to work fine. Logs here.

I can't open your RAR with 7-Zip. It appears to be corrupt.

I'd suggest a zip file. It is more of a standard and is directly supported by Windows.

[A.Fenderson]

Nothing major, but I ran a batch sequence containing several of the Xmen movie Blu-rays from the "X-Men and the Wolverine Collection", movie-only backup to BD25 for each, and the disc which was ripped as "X2" was renamed to "DATA" during processing and for the output folder.

[jdobbs]

Originally Posted by A.Fenderson

Nothing major, but I ran a batch sequence containing several of the Xmen movie Blu-rays from the "X-Men and the Wolverine Collection", movie-only backup to BD25 for each, and the disc which was ripped as "X2" was renamed to "DATA" during processing and for the output folder.

It wasn't done by BD-RB. There is nowhere in the code that a file or folder called "DATA" is created. The output folder name comes directly from the source folder name unless it is coming directly from a disc, in which case the volume label is used (which, I suppose, could conceivably be called "DATA").

[gonca]

Originally Posted by jdobbs

It wasn't done by BD-RB. There is nowhere in the code that a file or folder called "DATA" is created. The output folder name comes directly from the source folder name unless it is coming directly from a disc, in which case the volume label is used (which, I suppose, could conceivably be called "DATA").

If the name is two characters or less it seems that the output is given the drive label as name. His source drive is probably called DATA.

[A.Fenderson]

Well, I'm not trying to argue here, mostly because it's really a non-issue, but I just double-checked my facts, and I'm not incorrect. The exact rip used is still on my HDD, named "X2" by AnyDVD-HD (I did not rename the rip folder) and the .m2ts file of the output folder "DATA" is the movie in question. Log is below.

==========================
[13:18:05] BD Rebuilder v0.46.14 (beta)
[13:18:05] BEGIN - BATCH SEQUENCE
==========================
-----------------------
[13:18:05] PROCESSING BATCH FILE [1]
----------------------
[03/10/14] BD Rebuilder v0.46.14 (beta)
[13:18:06] Source:  XMEN_D1_00013
  - Input BD size: 27.79 GB
  - Approximate total content: [01:44:20.295]
  - Target BD size: 22.95 GB
  - Windows Version: 5.1 [2600]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), Two Pass
  - Decoding/Frame serving: DirectShow
  - Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[13:18:06] PHASE ONE, Encoding
 - [13:18:06] Processing: VID_00074 (1 of 1)
 - [13:18:06] Extracting A/V streams [VID_00074]
 - [13:27:14] Reencoding video [VID_00074]
   - Source Video: MPEG-4 (AVC), 1920x1080
   - Rate/Length: 23.976fps, 150,097 frames
   - Bitrate: 26,720 Kbs
 - [13:27:15] Reencoding: VID_00074, Pass 1 of 2
 - [15:05:34] Reencoding: VID_00074, Pass 2 of 2
 - [23:34:38] Video Encode complete
 - [23:34:38] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
   - Track 4353 (eng): Keeping original audio
   - Track 4357 (eng): Keeping original audio
[23:34:38]PHASE ONE complete
[23:34:38]PHASE TWO - Rebuild Started
 - [23:34:39] Rebuilding BD file Structure
[00:17:10] - Encode and Rebuild complete
 - WORKFILES folder removed.
[00:17:12] JOB: XMEN_D1 finished.
-----------------------
[00:17:13] PROCESSING BATCH FILE [2]
----------------------
[03/11/14] BD Rebuilder v0.46.14 (beta)
[00:17:18] Source:  DATA_00013
  - Input BD size: 29.52 GB
  - Approximate total content: [02:13:47.477]
  - Target BD size: 22.95 GB
  - Windows Version: 5.1 [2600]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), Two Pass
  - Decoding/Frame serving: DirectShow
  - Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[00:17:18] PHASE ONE, Encoding
 - [00:17:18] Processing: VID_00074 (1 of 1)
 - [00:17:18] Extracting A/V streams [VID_00074]
 - [02:02:42] Reencoding video [VID_00074]
   - Source Video: MPEG-4 (AVC), 1920x1080
   - Rate/Length: 23.976fps, 192,467 frames
   - Bitrate: 19,793 Kbs
 - [02:02:43] Reencoding: VID_00074, Pass 1 of 2
 - [04:03:30] Reencoding: VID_00074, Pass 2 of 2
 - [13:06:36] Video Encode complete
 - [13:06:36] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
   - Track 4353 (eng): Keeping original audio
   - Track 4357 (eng): Keeping original audio
   - Track 4358 (eng): Keeping original audio
[13:06:36]PHASE ONE complete
[13:06:36]PHASE TWO - Rebuild Started
 - [13:06:37] Rebuilding BD file Structure
[13:44:44] - Encode and Rebuild complete
 - WORKFILES folder removed.
[13:44:45] JOB: DATA finished.
-----------------------
[13:44:45] PROCESSING BATCH FILE [3]
----------------------
[03/11/14] BD Rebuilder v0.46.14 (beta)
[13:44:48] Source:  XMEN_THELASTSTAND_00013
  - Input BD size: 20.80 GB
  - Approximate total content: [01:44:05.238]
  - Target BD size: 22.95 GB
  - Windows Version: 5.1 [2600]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), Two Pass
  - Decoding/Frame serving: DirectShow
  - Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[13:44:49] PHASE ONE, Encoding
 - [13:44:49] Processing: VID_00074 (1 of 1)
 - [13:44:49] Extracting A/V streams [VID_00074]
 - [14:43:15] Reencoding video [VID_00074]
 - [14:43:15] Keeping original video (no reencode)
 - [14:43:15] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
   - Track 4353 (eng): Keeping original audio
   - Track 4357 (eng): Keeping original audio
   - Track 4358 (eng): Keeping original audio
[14:43:15]PHASE ONE complete
[14:43:15]PHASE TWO - Rebuild Started
 - [14:43:15] Rebuilding BD file Structure
[15:12:55] - Encode and Rebuild complete
 - WORKFILES folder removed.
[15:12:56] JOB: XMEN_THELASTSTAND finished.
-----------------------
[15:12:56] PROCESSING BATCH FILE [4]
----------------------
[03/11/14] BD Rebuilder v0.46.14 (beta)
[15:12:59] Source:  XMEN_WOLVERINE_00010
  - Input BD size: 27.87 GB
  - Approximate total content: [01:47:21.393]
  - Target BD size: 22.95 GB
  - Windows Version: 5.1 [2600]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), Two Pass
  - Decoding/Frame serving: DirectShow
  - Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[15:12:59] PHASE ONE, Encoding
 - [15:12:59] Processing: VID_00074 (1 of 1)
 - [15:12:59] Extracting A/V streams [VID_00074]
 - [16:28:23] Reencoding video [VID_00074]
   - Source Video: MPEG-4 (AVC), 1920x1080
   - Rate/Length: 23.976fps, 154,439 frames
   - Bitrate: 25,547 Kbs
 - [16:28:23] Reencoding: VID_00074, Pass 1 of 2
 - [18:11:34] Reencoding: VID_00074, Pass 2 of 2
 - [03:47:02] Video Encode complete
 - [03:47:02] Processing audio tracks
   - Track 4352 (eng): Keeping original audio
   - Track 4353 (eng): Keeping original audio
   - Track 4357 (eng): Keeping original audio
   - Track 4358 (eng): Keeping original audio
[03:47:02]PHASE ONE complete
[03:47:02]PHASE TWO - Rebuild Started
 - [03:47:10] Rebuilding BD file Structure
[04:21:39] - Encode and Rebuild complete
 - WORKFILES folder removed.
[04:21:40] JOB: XMEN_WOLVERINE finished.
==========================
[04:21:40] END - BATCH SEQUENCE
==========================

I also just started a movie-only backup (non-batch) of the same rip (it's still running), with a BD50 target/output, and the log file already shows that it's referring to the source directory as "DATA_00013", and the .inf file contains the following line:
"LABEL=DATA"
The source path as seen in the BD-RB GUI ends in "\X2\".
See below partial log.

----------------------
[03/12/14] BD Rebuilder v0.46.14 (beta)
[13:31:24] Source:  DATA_00013
  - Input BD size: 29.52 GB
  - Approximate total content: [02:13:47.477]
  - Target BD size: 46.26 GB
  - Windows Version: 5.1 [2600]
  - MOVIE-ONLY mode enabled
  - Quality: Highest (Very Slow), Two Pass
  - Decoding/Frame serving: DirectShow
  - Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[13:31:24] PHASE ONE, Encoding
 - [13:31:24] Processing: VID_00074 (1 of 1)
 - [13:31:24] Extracting A/V streams [VID_00074]

EDIT:
gonca (thank you) is correct: my hard drive disk label that the source rip sits on is called "DATA". At least now we know what's happening.

[Dream-Cypher]

So, Is anyone able to use Quick-Play Menus on a a PS3, when burned to a BD-R? I don't want to waste additional discs troubleshooting, if it's a PS3 issue, rather than something occurring when I author the disc.

Thanks,
Dream-Cypher

Originally Posted by Dream-Cypher

Hello,

I am having an issue where BD-R's with Quick-Play menus will not play on my PS3. I searched here, but was unable to find if this was a known issue.

The discs are built and burned successfully, and work fine on TMT5 and my Standalone Sony player. When I use them in the PS3, I get a black screen with no menus, and cannot do anything other than exit to the PS3 system menu.

If I press the "display" button, it shows me no time codes or title information. Attempting to hit the menu button tells me "This operation is not available here"

One of the discs was a standard BD backup, and the other was a disc created by importing several DVDs in Quick-Author mode. There are no errors in the BD-Rebuilder.log file, and as mentioned, the discs work fine in the other players I've tried. I have tried them in both a fat and slim PS3.

The DVD compilation was created in version .46.14 while the Movie backup was created in .46.11 a while ago. (I had not tried it in the PS3 previously, so I just found out that there was an issue.)

Thanks,
Dream-Cypher

[jdobbs]

Originally Posted by A.Fenderson

gonca (thank you) is correct: my hard drive disk label that the source rip sits on is called "DATA". At least now we know what's happening.

Originally Posted by jdobbs

...unless it is coming directly from a disc, in which case the volume label is used (which, I suppose, could conceivably be called "DATA").

Did you read this? If the name is 2 characters or less -- it has to assume it is the drive. That's because of the possible "d:\" that could precede the pathname.

[A.Fenderson]

Did you read this?....

I did read that, but we seem to have had a miscommunication, stemming from me taking what you wrote completely literally when it was seemingly meant in a more general way: the way you originally stated it didn't seem to match my scenario in that it wasn't pulling the source from "a disc" aka BD ("disc" = optical disk), it was pulling it from the hard disk drive, so without gonca's clarification that the name could be coming from the drive label of the source rip's location (and specific addition about the 2-character length issue) I didn't see the relevance.

If the name is 2 characters or less -- it has to assume it is the drive. That's because of the possible "d:\" that could precede the pathname.

Understood--thank you for explaining it; that makes sense. Sorry for my contribution to the noise:signal ratio in the thread, but I'm really not as dense as this exchange might imply.

[gonca]

@ A.Fenderson
Sorry I wasn't clearer with my statement.

[A.Fenderson]

@gonca: you were perfectly clear. Thank you.

[Weirdo]

Originally Posted by jdobbs

I can't open your RAR with 7-Zip. It appears to be corrupt.

Not corrupt, but RAR5. Here's the zip.

[jdobbs]

Originally Posted by A.Fenderson

I did read that, but we seem to have had a miscommunication, stemming from me taking what you wrote completely literally when it was seemingly meant in a more general way: the way you originally stated it didn't seem to match my scenario in that it wasn't pulling the source from "a disc" aka BD ("disc" = optical disk), it was pulling it from the hard disk drive, so without gonca's clarification that the name could be coming from the drive label of the source rip's location (and specific addition about the 2-character length issue) I didn't see the relevance.

Understood--thank you for explaining it; that makes sense. Sorry for my contribution to the noise:signal ratio in the thread, but I'm really not as dense as this exchange might imply.

Just to avoid confusion, I have changed the way it gets the name. It shouldn't be an issue anymore after the next release.

[Sharc]

@jdobbs
After 3 successful Quick-Play Backups, I run again into a non-working one which I had to IMPORT to make it working. Apparently the IMPORT function applies a kind of fix.
I checked with BDedit the structure an found a difference -- apart from the renumbering of the files. The difference is in the 00001.mpls (for the feature).

Non-working disc: In the STN table the flag IG is set and refers to a sub-path
Working disc: In the STN table the flag IG is not set and hence no reference to a sub-path

It seems like this is the only difference, so could this perhaps be the cause for the problem?
If it helps I could send you some files.

[jdobbs]

Originally Posted by Sharc

@jdobbs
After 3 successful Quick-Play Backups, I run again into a non-working one which I had to IMPORT to make it working. Apparently the IMPORT function applies a kind of fix.
I checked with BDedit the structure an found a difference -- apart from the renumbering of the files. The difference is in the 00001.mpls (for the feature).

Non-working disc: In the STN table the flag IG is set and refers to a sub-path
Working disc: In the STN table the flag IG is not set and hence no reference to a sub-path

It seems like this is the only difference, so could this perhaps be the cause for the problem?
If it helps I could send you some files.

I'll look at it. If there is a subpath referenced (usually an out-of-mux IGS stream), the reference should be kept in the Quick-Play backup and not in an import. Importing essentially just keeps playitems that match your import rules, and removes all the bells-and-whistles. Can you tell me if the M2TS associated with the IGS stream (subpath) exists in the STREAM folder of the Quick-Play authored disc? (It should). BDEdit can show the name of the M2TS.

[Sharc]

Originally Posted by jdobbs

I'll look at it. If there is a subpath referenced (usually an out-of-mux IGS stream), the reference should be kept in the Quick-Play backup and not in an import. Importing essentially just keeps playitems that match your import rules, and remove all the bells-and-whistles. Can you tell me if the M2TS associated with the IGS stream (subpath) exists in the STREAM folder of the Quick-Play authored disc? (It should). BDEdit can show the name of the M2TS.

Not sure if this answers your question:
Stream Folder of non-working disc (total 3 files):
- 00021.m2ts (Feature)
- 99001.m2ts (menu backdrop)
- 99002.m2ts (ID: 256 (0x100) Menu ID : 1 (0x1) List : 5120 (0x1400) ()

Stream Folder of working disc (total 3 files):
- 00001.m2ts (Feature)
- 99001.m2ts (menu backdrop)
- 99002.m2ts (ID : 256 (0x100) Menu ID : 1 (0x1) List : 5120 (0x1400) ()

So both stream folders look the same, except file number for the Feature

The sub-Path of the non-working disc refers to sPID1400 which seems to be 99002.m2ts

[jdobbs]

Originally Posted by Sharc

Not sure if this answers your question:
Stream Folder of non-working disc (total 3 files):
- 00021.m2ts (Feature)
- 99001.m2ts (menu backdrop)
- 99002.m2ts (ID: 256 (0x100) Menu ID : 1 (0x1) List : 5120 (0x1400) ()

Stream Folder of working disc (total 3 files):
- 00001.m2ts (Feature)
- 99001.m2ts (menu backdrop)
- 99002.m2ts (ID : 256 (0x100) Menu ID : 1 (0x1) List : 5120 (0x1400) ()

So both stream folders look the same, except file number for the Feature

The sub-Path of the non-working disc refers to sPID1400 which seems to be 99002.m2ts

There should be two MPLS files in the PLAYLIST folder. One of those is for the feature and the other is for the menu. The menu set (99001/99002) would be contained in the higher numbered of the two MPLS files. 99002 contains an out-of-mux IGS (Interactive Graphics Stream) for the menu (the actual selections that are overlaid on the menu backdrop). The lower numbered MPLS would reference the feature.

In a Quick-Play backup it is also possible that feature may have IGS (although most of the time it doesn't) -- that's usually for some graphic feature that pops-up upon request. Sometimes it's things like a graphic of the original storyboards or something similar. The PID for that stream would also be 0x1400 (the base PID for an IGS).

The out-of-mux IGS for the feature would be named the same as it was on the original disc. From what you have shown me there doesn't appear to have been one, or there would have been four M2TS files in the STREAM folder. If BDEdit shows that there is a subpath listed for the lessor-numbered MPLS, then it would appear that BD-RB kept the reference, but not the file -- which, of course, would be a bug.

What I don't understand is why there is even a menu when there is only one item to be played? Normally a menu is not created for a single playback item unless the hidden option MENU_FORCE_QUICK=1 is established. I assume you have that set in your INI file?

I'll dig around and see if I can find a disc with out-of-mux IGS in the feature and do a Quick-Play backup just to see what I can find. But, the more I think about it, maybe I should eliminate the IGS subpaths on a Quick-Play backup. There are other possible headaches that could conceivably come out of an IGS stream -- since the commands really have no limit to their actions.

[mparade]

In edit mode, if I right-click on one VID and choosing "preview this item" BD-RB starts a "extracting A/V streams" process taking several minutes like it used to execute right before encoding the streams. I have found this "issue" with just a few VIDs on the extra disc of Harry Potter And The Deathly Hallows. It wouldn' t be a problem for me, but when BD-RB had started encoding these streams it got stuck and seemed to be running an infinite encoding process showing that the source video is 1 frame long and that the encoded frame number kept raising upto as far as infinite

If someone has any idea, please help.

Thank you!

[jdobbs]

Originally Posted by mparade

In edit mode, if I right-click on one VID and choosing "preview this item" BD-RB starts a "extracting A/V streams" process taking several minutes like it used to execute right before encoding the streams. I have found this "issue" with just a few VIDs on the extra disc of Harry Potter And The Deathly Hallows. It wouldn' t be a problem for me, but when BD-RB had started encoding these streams it got stuck and seemed to be running an infinite encoding process showing that the source video is 1 frame long and that the encoded frame number kept raising upto as far as infinite

If someone has any idea, please help.

Thank you!

It was likely an interlaced VC-1 file and you are using DirectshowSource(). Normally the viewer will simply open the M2TS directly and play back the source. But there are some VC-1 sources that DirectshowSource() can't handle directly from within an M2TS. In that case the only way to view them is to extract them, create an MKV, and play the MKV.

So I guess what I'm saying is that it isn't a bug, it's a feature. The only other alternative is to say "I can't view this". So it's an annoying feature -- but one that is necessary.

As for the encoding issue -- I'd have to know more. How long did you let it run? What mode was it in? Have you tried more than one mode (DirectshowSource & LAVF)?

[Sharc]

Originally Posted by jdobbs

There should be two MPLS files in the PLAYLIST folder. One of those is for the feature and the other is for the menu. The menu set (99001/99002) would be contained in the higher numbered of the two MPLS files. 99002 contains an out-of-mux IGS (Interactive Graphics Stream) for the menu (the actual selections that are overlaid on the menu backdrop). The lower numbered MPLS would reference the feature.

Yes, this is what I see on both disks (working and non-working)

In a Quick-Play backup it is also possible that feature may have IGS (although most of the time it doesn't) -- that's usually for some graphic feature that pops-up upon request. Sometimes it's things like a graphic of the original storyboards or something similar. The PID for that stream would also be 0x1400 (the base PID for an IGS).

Working disk:
00001.mpls refers to 00001.m2ts with no IGS
Non-working disc:
00001.mpls refers to 00021.m2ts with IGS

The out-of-mux IGS for the feature would be named the same as it was on the original disc. From what you have shown me there doesn't appear to have been one, or there would have been four M2TS files in the STREAM folder. If BDEdit shows that there is a subpath listed for the lessor-numbered MPLS, then it would appear that BD-RB kept the reference, but not the file -- which, of course, would be a bug.

This seems to be the case if my interpretation of BDedit is correct .....

What I don't understand is why there is even a menu when there is only one item to be played? Normally a menu is not created for a single playback item unless the hidden option MENU_FORCE_QUICK=1 is established. I assume you have that set in your INI file?

Exactly. It's convenient to insert a "Play movie" button this way.

I'll dig around and see if I can find a disc with out-of-mux IGS in the feature and do a Quick-Play backup just to see what I can find. But, the more I think about it, maybe I should eliminate the IGS subpaths on a Quick-Play backup. There are other possible headaches that could conceivably come out of an IGS stream -- since the commands really have no limit to their actions.

My disc is "Frozen Ground", (Region 2).

Edit:
Another problematic disc was "Game of Thrones" (S1D1, Region 2).
It has no IGS but sV and sA (IM PIP) with makes the disc non-playable. IMPORT removes these and makes the disk playable -- my speculative conclusion only.