BD Rebuilder Beta - Bug Reports Only

[omegaman7]

there are no issues with running any program like BDRB or another in the program files. I do, well not if u disable that stupid UAC like i did. Thats one of the first things i do after a windows install.

Me too. Pesky function In my opinion.

[abbadon]

any plan to make MULTIPROCESS work with IMPORT ? with my current Phenom II x4 940 it makes a 20% difference. I was planning on purchaching a 6 core Intel after extensive testing on such a machine, but my testing showed MULTIPROCESS gave an even greater boost from MULTIPROCESS (ca. 40%). Granted, I see myself doing VERY few imports, but is this conflict considered a bug-to-be-fixed ? or is there a manual workaround you can suggest?

[soneca]

jdobbs,

All programs installed correctly, the windows registry was changed to allow me to use the revision(3882) of ffdshow with BD Rebuilder and RipBot264.
So it appears the 9999.

http://i131.photobucket.com/albums/p305/soneca1/Forum/BD-1.jpg

This time the conversion was completed but the BD Rebuilder is detecting bff as tff.
Bd Rebuilder should detect the correct order of the dominant field or the inclusion of the parameter "--bff" is always necessary?
I made another conversion including this parameter, and the video was processed correctly.

TWEAK_PASS_ONE=--tune film --bff
TWEAK_PASS_TWO=--tune film --bff

[mercadonegro]

mercadonegro

Do you have BD-RB installed in the Program Files or the Program Files (x86) folders?

Windows 7 doesn't always play nice with BD-RB if you put it there.

Hello jwjohnson
BD-RB I have not installed in the Program Files or Program Files (x86)
I have it installed on another hard drive.
E: \ Mercadonegro \ in process \ Compression \ BD_Rebuilder
But when I choose to keep the DTS audio, I have no problem ...

[mercadonegro]

@mercadonegro

Error 00070 is "Permission Denied" -- you have a permissions issue with either the application or the folder where it is attempting to write.

I'd right-click on the files AFTEN.EXE and WAVI.EXE in the BD-RB tools folder and see if there is some rights issue against one of them.

Hi jdobbs

OK. I right click on AFTEN.EXE and WAVI.EXE, on the Details tab, but no rights issue
My English is not good. Apologies.

[jdobbs]

Hi jdobbs

OK. I right click on AFTEN.EXE and WAVI.EXE, on the Details tab, but no rights issue
My English is not good. Apologies. The conversion is run as a batch job (in order to redirect the output of WAVI into AFTEN). So that might be another place to look. Unfortunately this is definitely a rights/privilege issue, which is specific to your system. It's tough to debug one of those on a forum, there are lots of possibilities.

[aneurysm]

hi,
this is not a bug .. but something I haven't found yet.
is there an option to select to which language audio or subs are changed ?
for instance .. a disc with 20 different subs. I have standard selected to keep ENG & DUT subs.
After the rebuild, all the subs that are gone are replaced by ENG (So I have 19 ENG subs & 1 DUT sub). But what if I would like them to all be replaced by DUT (19 DUT subs & 1 ENG sub)?

tnx in advance

[jdobbs]

hi,
this is not a bug .. but something I haven't found yet.
is there an option to select to which language audio or subs are changed ?
for instance .. a disc with 20 different subs. I have standard selected to keep ENG & DUT subs.
After the rebuild, all the subs that are gone are replaced by ENG (So I have 19 ENG subs & 1 DUT sub). But what if I would like them to all be replaced by DUT (19 DUT subs & 1 ENG sub)?

tnx in advance Currently the languages that are not kept are modified to point to the first of the languages that are. So if ENG is first on the list of selected languages, the track id for all the removed languages are changed to point to ENG. If the first was DUT, then they'd point to DUT. I could probably add a hidden parameter that gives precedence to some other language.

[aneurysm]

Currently the languages that are not kept point are modified to point to the first of the languages that are. So if ENG is first on the list of selected languages, the track id for all the removed languages are changed to point to ENG. If the first was DUT, then they'd point to DUT. I could probably add a hidden parameter that gives precedence to some other language.

ok that explains. ENG is indeed usually first. If ya ever have time to put that in a hidden options would be cool.

[AmigaFuture]

Toy Story 1 (and 2): I removed AnyDVD and installed an older version 6.7.6.0..and noticed a difference in handling this disk with most recent releases; with respect to the ripping to HDD vs ISO. BD-RB is unable to create a backup of Toy Story without A/V "jerkiness" with my machines, even the almost completely stock Windows 7. Installed games, Firefox and Crome are the only things keeping it from being stock Windows 7. BD-RB does render a good MKV as an alternate output. I read a little more about "linking" which is why 3D Blu-ray disks are to be ripped as ISO. Toy Story isn't 3D, but I wonder if BD-RB isn't "linking" the segments correctly!? Just pondering... Thanks for reading.

Until something changes with BD-RB or some other clue is noticed, I'm out of ideas. :D

[Adbear]

The reason 3D discs need to be ripped as ISO's is so the right eye doesn't get unpacked and make it to big to fit back onto a disc, this is not the same as seamless branching that you get on 2D discs

[AmigaFuture]

Adbear: I was reading about that on the SlySoft forums when someone else talked about it. Now I get "Why" without all the details. Okay, I'll change it to seamless branching..perhaps that's what's happening with Toy Story 1 and 2 here with BD-RB. I'm not sure. Seems odd to me to call it "the right eye" when it's not an actual "Eye"...but only data for it. Ah, well. Hehe. I appreciate your reply, thanks.

[sytyguy]

So does that mean one can rip a 3D movie with BD-RB if it is ripped as an ISO???

[jdobbs]

Adbear: I was reading about that on the SlySoft forums when someone else talked about it. Now I get "Why" without all the details. Okay, I'll change it to seamless branching..perhaps that's what's happening with Toy Story 1 and 2 here with BD-RB. I'm not sure. Seems odd to me to call it "the right eye" when it's not an actual "Eye"...but only data for it. Ah, well. Hehe. I appreciate your reply, thanks. That doesn't explain why it worked correctly for hundreds of others -- including myself.

Here's what I'd like to happen. I want you to run "Toy Story" again -- then , without changing anything, I'd like you to copy the config/ini file contents and send them to me (dvd-rb@dvd-rb.com). I will load your settings and run "Toy Story" one more time. If I can repeat your issue -- I'll get it fixed. If it runs correctly for me, then I'll just have to tell you that the problem is on your end and be done with it.

[Ch3vr0n]

So does that mean one can rip a 3D movie with BD-RB if it is ripped as an ISO???

Yes and no. BDRB will be able to produce a 2D only backup disc provided the disc containts both a 2D & 3D version on the same disc. BDRB simply ignores the SSIF folder and processes the rest. If it is a 3D only disc, then no BDRB can't handle it. The only way to backup a 3D disc and retain full functionality like the original is 1:1

[sytyguy]

I know the documentation indicates it cannot, but "Adbear" mentioned, "3D discs need to be ripped as ISO's", so I thought something had changed.

Thanks for the reply.

[drmih]

If a 3D disc is ripped to a folder the size is effectively twice the size on disc. Therefore it makes sense to rip to an iso for storage. The only software that can currently create a bd-25 iso of a 3D disc with everything cloned is dvdfab.

[Ch3vr0n]

euhm you're wrong on that part. DVDCrap can shrink BD3D to BD25 as much as i'm santa. it can't, it does the same thing BDRB does. Ignore the SSIF folder, but keeps the menu intact. Result BD25 disc on which the 3D stream doesnt work.

[drmih]

Just do your homework. I have version 8.2.1.2 and it works on my discs - I've backed up 30 or so of my discs and the copies are full 3D copies on bd-25. The stupid thing about the software is that the option lets you write to a folder or iso image, and normally I'd just go to a folder. If you do this it does ignore the SSIF folder - it only works properly if you select iso as the output.

Here's a listing of the bd50 and bd25 discs:

Volume in drive E is CLASH OF THE TITANS 3D BD
Volume Serial Number is 0118-93E6

Directory of e:\bdmv\stream\ssif

25/06/2010 22:30 <DIR> .
25/06/2010 22:30 <DIR> ..
25/06/2010 22:30 40,643,745,792 00002.ssif
25/06/2010 22:30 50,583,552 00004.ssif
25/06/2010 22:30 1,910,784 00006.ssif
25/06/2010 22:30 8,091,648 00008.ssif
25/06/2010 22:30 1,044,480 00010.ssif
25/06/2010 22:30 125,884,416 00012.ssif
25/06/2010 22:30 2,537,472 00014.ssif
25/06/2010 22:30 693,061,632 00016.ssif
25/06/2010 22:30 239,616 00018.ssif
9 File(s) 41,527,102,064 bytes
2 Dir(s) 0 bytes free

Volume in drive E is CLASH OF THE TITANS 3D BD
Volume Serial Number is F7D6-93DD

Directory of e:\bdmv\stream\ssif

01/01/1970 01:00 <DIR> .
08/09/2012 19:30 <DIR> ..
08/09/2012 19:23 22,236,856,320 00002.ssif
08/09/2012 19:24 26,529,792 00004.ssif
08/09/2012 19:30 1,910,784 00006.ssif
08/09/2012 19:24 5,947,392 00008.ssif
08/09/2012 19:24 485,376 00010.ssif
08/09/2012 19:30 141,821,952 00012.ssif
08/09/2012 19:23 1,572,864 00014.ssif
08/09/2012 14:18 495,814,656 00016.ssif
08/09/2012 19:23 24,576 00018.ssif
9 File(s) 22,910,966,780 bytes
2 Dir(s) 0 bytes free


Don't forget my present this year Santa!

euhm you're wrong on that part. DVDCrap can shrink BD3D to BD25 as much as i'm santa. it can't, it does the same thing BDRB does. Ignore the SSIF folder, but keeps the menu intact. Result BD25 disc on which the 3D stream doesnt work.

[Ch3vr0n]

In that case i have some testing to do. It didn't do that the last time i heard about it's so called "shrinking" option. Which option do i pick. Got a couple discs lying arround, i wonder what the quality will be

[drmih]

Just read on the fly, or if you have already ripped to an iso, pick that up in the Full Copy mode. It automatically identifies it as a 3D disk. The trick is to save the output as an iso image and to change the output size to bd-25. I have only ever done mine from iso images ripped to the HDD, and output as an iso image on the hdd (so that I can mount and check it first).

Prometheus arrived today and I have already successfully made a bd-25 3D copy. To stop hijacking the thread, just pm me if you have any problems getting it to work.

[Ch3vr0n]

oi, i didn't start the hijack. U did. That being said already found out how to do it. Now back on topic

[RobertM]

Chevron, you should re-read your last response. It comes across as a little rude, which I'm sure wasn't the intent, considering that Drmih taught you something useful, and has offered personal assistance if you need it.

[drmih]

It's fine - I did hijack it but I knew there might be a few people who'd want to know more about how to do it and didn't want it in this thread - said multiple pms did arrive!

[Wizzu]

[Off topic]

"To stop hijacking the thread, just pm me if you have any problems getting it to work. "

Read/interpreted by Ch3vr0n as "stop highjacking the thread, PM me if you're too stupid to find it out on your own", thus his reaction.

I read/interpreted drmih's input rather differently, more like "I'm willing to help, but we are kinda highjacking the thread, so PM me if you want my help". )

Communication is fascinating. ;)

[/Off topic]
-----
September 7th, 2012 - v0.42.1
[...]
- Added a new hidden setting, IMPORT_FOLDER, which
allows you to select a location where any interim
imported items are kept.
[...]


This makes me think of something. Wouldn't it be also interesting to have the option to select (when possible) a different location for the WORKING folder than for the final target folder?

Let me make my point clearer. :)

Disc activity is pretty intensive during encoding and rebuild. So, I'm under the impression that (for those of us who have several physical disks) it could save encoding time to have the source to encode (the rip) on disk A, the working folder on disk B, and the target folder on disc C. Am I wrong? :confused:

[jdobbs]

[Off topic]

"To stop hijacking the thread, just pm me if you have any problems getting it to work. "

Read/interpreted by Ch3vr0n as "stop highjacking the thread, PM me if you're too stupid to find it out on your own", thus his reaction.

I read/interpreted drmih's input rather differently, more like "I'm willing to help, but we are kinda highjacking the thread, so PM me if you want my help". )

Communication is fascinating. ;)

[/Off topic]
-----


This makes me think of something. Wouldn't it be also interesting to have the option to select (when possible) a different location for the WORKING folder than for the final target folder?

Let me make my point clearer. :)

Disc activity is pretty intensive during encoding and rebuild. So, I'm under the impression that (for those of us who have several physical disks) it could save encoding time to have the source to encode (the rip) on disk A, the working folder on disk B, and the target folder on disc C. Am I wrong? :confused: I've answered this several times in this thread. I did considerable testing -- and the fact is that it doesn't help. It makes it slower. Most of the time, for various reasons, all the work has to be done in the working folder (e.g. building the M2TS), and then it is just "moved" to the output folder. If you point to a different drive it will actually take longer because it has to be copied/deleted rather than moved. In a move nothing actually happens to the huge file itself -- all that is changed is the file pointer of the file system referencing a different folder, and it only takes a few milliseconds. You might save yourself a little in required hard drive space -- but not enough to make much of a difference considering the size of most modern drives.

[Wizzu]

I've answered this several times in this thread. Oh I see, accept my apologies, then. I did considerable testing -- and the fact is that it doesn't help. [....] Thanks for the explanations, they make perfect sense to me.
Looks like I had a distorted idea of the chain of events during BDRB's work :D

[jdobbs]

Oh I see, accept my apologies, then.Thanks for the explanations, they make perfect sense to me.
Looks like I had a distorted idea of the chain of events during BDRB's work :D Not too distorted. If it didn't have potential I wouldn't have tested it in the first place. :)

[RobertM]

It makes a lot of sense, what JDObbs says, once you think about it.

Anybody can confirm his statement about moving on the same drive vs. moving to a different drive. Try it yourself: take a rebuilt BD folder and drag/drop it to a different location on the same drive -- takes no time; now try dragging dropping to a different drive -- takes ages.

When a different drive location would make sense is if the content of the file is changed, so you must rewrite all of the info instead of just moving it over unchanged. This would be the case when re-encoding video/audio, where the actual bits in the file change. In this case, it would definitely be faster to use another drive, but ONLY if the drive read/write times are a bottleneck. As most of us have seen, it doesn't take too much time to extract the data, but it takes hours to re-encode (depending on settings). Speeding up the read/write would make no practical difference because the processor is laboring away crunching data and is never really waiting on a read/write operation.

[Wizzu]

Anybody can confirm his statement about moving on the same drive vs. moving to a different drive. Of course. :)

My distorted vision was that the chain of events was these 3 steps:

1. Extract AV streams from the BD rip to the WORKFILE folder
(BTW this part is faster when source and destination are on 2 diff. physical discs - at least it is with my setup)

2. Compress/process these AV streams from, and to, the WORKFILES folder
that's the step that I thought could also be faster if 2 diff. locations were used

3. Rebuild the M2TS and BD structure from the compressed files.
This is not a step I thought could benefit from 2 diff. locations.

Now from jdobbs's explanations, I gather that my vision of step 2 is plain wrong. I guess only part of the needed files for encoding are in the WORFILE folder after step 1, and that most of the processing (step 2) is actually done from files that are still in the original rip location.

Then again, I can be wrong... again. :D

Whatever, I'll take jdobb's word for it that no further time can be gained @step2 by using different physical locations.
And just enjoy the program. :cool:

[jdobbs]

Actually step 2 is correct, and is how it is done now. When Compressing/Processing you are, in essence, moving data from the SOURCE folder, and processing it into the WORKING folder. The output of STEP 1 is in most cases only the audio/subs. The video is extracted, but only so that it can be used in the event that it doesn't need to be reencoded. That is very rare and in most instances the video is immediately removed following demux. The input to X264 (in step 2) is the source M2TS (via AVISYNTH or LAVF).

So... if you use a different physical drive for the SOURCE and the WORKING folders (as I always do) you will get a speed increase.

The total time used in steps 1 & 3 is almost insignificant compared to step 2.

[RobertM]

1. Extract AV streams from the BD rip to the WORKFILE folder
(BTW this part is faster when source and destination are on 2 diff. physical discs
Right. That's the way I set up my system, and it definitely saves time that way.

I guess only part of the needed files for encoding are in the WORFILE folder after step 1, and that most of the processing (step 2) is actually done from files that are still in the original rip location.

I don't think that's right. As far as I know step 2 takes place using files residing entirely in the workfiles folder.

My point was that the processor is the bottleneck, and that any read/write issues are negligible because the processor is never starved for data.

Anyway, that's all moot. JDobbs has done the validation work, so I feel quite comfortable leaving it as that. And, even if there were a slight, slight speed advantage, I'm not sure that it would justify further cluttering the "Setup" UI.

[RobertM]

When Compressing/Processing you are in essence moving data from the SOURCE folder, and processing it omto the WORKING folder.

Maybe I'm confused. Wouldn't be the first time ;)

[Wizzu]

Actually step 2 is correct, and is how it is done now. When Compressing/Processing you are, in essence, moving data from the SOURCE folder, and processing it into the WORKING folder. Help, :scared: now I'm confused too, since these two sentences are in contradiction! :confused:

"My" step 2 (the one I gathered that was wrong, but you're now referring to as being right) was that processing took place entirely FROM and TO the WORFILE folder, thus not accessing the source (rip) folder anymore.

But your second sentence seems to confirm my recent intuition, which was that during compresion/processing, data from the source (rip) folder is actually still accessed.

Then you mention that (during step 1) "the video is extracted, but only so that it can be used in the event that it doesn't need to be reencoded", which was the missing piece of the puzzle for me, allowing me to understand why my vision of the whole thing was distorted in the first place.

So how on earth could "my" step 2 (as in post #15933) be correct...??? :confused:

[omegaman7]

The working folder is the output folder. In the final step, only directories are changed(fractions of a second). Makes perfect sense to me :) Faster hard drive = lower latency. Even a slow hard drive should be able to keep up with a VERY busy processor though.

[jdobbs]

Help, :scared: now I'm confused too, since these two sentences are in contradiction! :confused:

"My" step 2 (the one I gathered that was wrong, but you're now referring to as being right) was that processing took place entirely FROM and TO the WORFILE folder, thus not accessing the source (rip) folder anymore.

But your second sentence seems to confirm my recent intuition, which was that during compresion/processing, data from the source (rip) folder is actually still accessed.

Then you mention that (during step 1) "the video is extracted, but only so that it can be used in the event that it doesn't need to be reencoded", which was the missing piece of the puzzle for me, allowing me to understand why my vision of the whole thing was distorted in the first place.

So how on earth could "my" step 2 (as in post #15933) be correct...??? :confused: I can see how you'd be confused. I guess I should have written my own steps instead of referencing yours. Your statement is correct in that you say it is the "compress/process step" -- the only thing that is wrong is that you say "from, and to" when actually it is only "to". The "from" is the SOURCE folder. The exception is the audio streams which are either reencoded or used intact from the WORKING folder -- but that only takes a few minutes of the entire rebuild process. Subtitles are always used intact (unless they have to be converted for DVD output).

The reason I extract the video is that it doesn't add anything in terms of time since I have to extract the audio anyway. That way it is available if it will fit "as-is". I then remove it if it has to be reencoded (to save space).

[Wizzu]

the only thing that is wrong is that you say "from, and to" when actually it is only "to". Pfffeeeeewww (heaving a sight with ease :D) - that was an important detail that I wasn't sure I got right (BTW I did...) and this clarification of yours is very welcome because it lifts the doubt in my mind.

Thanks, no confusion left here :goodpost:

[Wizzu]

I don't think that's right. As far as I know step 2 takes place using files residing entirely in the workfiles folder.And that's what I originally thought too, because of the folder size right after the extraction.
We now both know that we were wrong, and more importantly, why we were.My point was that the processor is the bottleneck, and that any read/write issues are negligible because the processor is never starved for data.That was a good point nonetheless. :)

[AmigaFuture]

It's funny how people try to "Save Time" into a little box for "later" when it's Always ~Now~ and constantly changing because of their thoughts/preferences and cannot be "saved". I once held that "mindset", or "concept"..until I decided to check Inside a lot more. :D

Thanks for the suggestion, Jdobbs, about emailing. I'm checking a couple things before I do that. If 2 movies seem to be effected, then more may be and I want to know what the root of the challenge is I've noticed. What model is your Blu-ray Burner? Mine might be faulting and I'm checking that.

Thank You.

[omegaman7]

My iHES108 began causing read errors. One is rather odd. The rip appeared fine, but the encode didn't go well. But when ripped with another drive, the output was fine. I guess just enough information was mutated enough, to not notice visually, but effected the helper apps. Wouldn't be the first Lite-on to give me grief. THough I've had another lite-on that was VERY good. I currently use two LG's. A WH10LS30(only reading/burns unreliably), and a WH12LS39 for my burning/reading. I slapped a 3yr warrantly on that bad boy :)

[Random987]

Since upgrading to v0.42.03, I experienced the following error:

BD Rebuilder experienced an error 1506 [11:26:39] DoEncoding() 00052 1506

I tried it both on a new burn (backing up Toy Story) and one that previously worked before (50/50). I received the same error. Inspect.exe doesn't show any problems.

Any ideas?

[Ch3vr0n]

Mind posting the actual bdrb log and the actual inspect.exe results. Don't just tell inspect reports everything OK, we need to see the actual output.

Verstuurd van mijn HTC Sensation XE with Beats Audio Z715e met Tapatalk

[jdobbs]

Since upgrading to v0.42.03, I experienced the following error:

BD Rebuilder experienced an error 1506 [11:26:39] DoEncoding() 00052 1506

I tried it both on a new burn (backing up Toy Story) and one that previously worked before (50/50). I received the same error. Inspect.exe doesn't show any problems.

Any ideas? Look for illegal characters in your installation path. At that point (1506) all BD-RB is trying to do is read from the INF file, a very simple function -- and it is getting a "Bad filename" error (0052). The actual filename of the INI file is always the same and BD-RB goes through that exact same code segment for every job it runs -- the only thing I can imagine is a pathname that has something goofy involved.

[Random987]

Here is my log file:

----------------------
[10/09/12] BD Rebuilder v0.42.03 (beta)
[14:28:41] Source: TOY_STORY_PLAYLIST_00150
- Input BD size: 19.48 GB
- Approximate total content: [01:21:04.901]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: High-Speed Option (BD-25), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
- [14:28:41] DoEncoding() 00052 1506
[14:28:43] - Failed to complete.

My Inspect.exe:

Windows Version: 6.1 [7601]
- AVISYNTH Version: [2.5.8.0], Ok
- HAALI Splitter: [1.9.42.1], Ok
- FFDSHOW: [3326], Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libmpeg2": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- AnyDVD settings check: Ok.
- BD Rebuilder v0.41.0.1, Ok
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok


The weird thing is that I haven't done anything different than any of my other backup attempts. I even tried one that worked previously and still got the same error.

With the file name, I choose that proper folder through the program's "browse" function. If I had to guess, the "source" from the above log file looks different.



Look for illegal characters in your installation path. At that point (1506) all BD-RB is trying to do is read from the INF file, a very simple function -- and it is getting a "Bad filename" error (0052). The actual filename of the INI file is always the same and BD-RB goes through that exact same code segment for every job it runs -- the only thing I can imagine is a pathname that has something goofy involved.

[jdobbs]

You completely missed the point of the post. What is the installation path?

[Random987]

I am not exactly sure what you mean.

The program is located at:

C:\Program Files (x86)\BD-RB\BD_Rebuilder




You completely missed the point of the post. What is the installation path?

[Random987]

Sorry guys, I am an idiot. I figured it out. I was trying to burn straight to a bluray disc (the working path was to the bluray). It has been a while....:o:o:o:o

[omegaman7]

So is "Error in attempt to multiplex (.Meta)" pretty much guaranteed to be a corrupt audio track? Which is essentially a bad rip. That sucks. Aw well. It's only the secondary DTS track thankfully.

Maybe it's the secondary video track. Guess I'll have to try movie only :S

Yup. Secondary video was buggered. I wish my reading drives would either let me know, or simply say it cannot copy...

[staros]

I discovered a bug with the CRF prediction algorithm.

If you choose to do 1-pass CRF, BD-RB performs several "runs" of short encodes in order to determine the appropriate CRF value to use for the whole source. The first two runs are upper and lower bound "tests" so BD-RB can get a feel of the source material. For instance, it may first try CRF 22.23 and then CRF 16.11. The results of these two runs determine what CRF value BD-RB should try in the third run. This process continues until BD-RB is confident it has honed in on the "ideal" CRF value and then starts the actual full encode using this value.

Here's the bug: I encoded a source whose target bitrate must have been very close to the output bitrate from the first prediction run. Instead of trying a second prediction run (the upper/lower "bound"), BD-RB encoded the entire source using the CRF value it would have used in the second run. So the final output ended up around 600MB instead of 4+ GB.

I apologize I don't have the log to post. But it may not require duplication to diagnose, as this seems like a simple logic error. Basically the code should either force itself to always perform 2 prediction runs before doing the full encode, or make sure the CRF value variable is correct before exiting the prediction loop.

Tell me if you need more details.

[AmigaFuture]

Omegaman7: If you listen to the drive as it rips, or watch AnyDVD at times..you'll know if there's a Read Error or Sector error or..if it's just dirty or scratched. They make noises and the Software shows pauses. My LG's (WH10LS30) Blue Light changes flickering when encountering possible challenges.