BD Rebuilder Beta - Bug Reports Only

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

[jdobbs]

Originally Posted by 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]
-----


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?

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]

Originally Posted by jdobbs

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

[jdobbs]

Originally Posted by Wizzu

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

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]

Originally Posted by RobertM

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.

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.

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

Originally Posted by Wizzu

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]

Originally Posted by jdobbs

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]

Originally Posted by 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.

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

"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...???

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

Originally Posted by Wizzu

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

"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...???

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]

Originally Posted by jdobbs

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 ) - 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

[Wizzu]

Originally Posted by RobertM

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.

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