BD Rebuilder Beta - Bug Reports Only

[Ch3vr0n]

There is only 1 solution to that problem. Use the recommended versions of the helper tools. Jdobbs has repeatedly stated that bug reports will NOT be accepted if you're using unsupported versions. Fix that guest p first, then come back

Verstuurd vanaf mijn Nexus 7 met Tapatalk

[jdobbs]

@scotlandman

You've given me a lot of information -- but haven't told me what issue you are having??? Does it not play back correctly?

[Guest]

"Second Media Info shows the Proper file information for some reason BD Rebuilder does not include file 00872.m2ts in the encode."

I suppose he expected 00872.m2ts to be included and it was not.

[jdobbs]

There is 25 bonus in 2D (3,5 GB) and I don't see in "Stream", I see only 3D files (0.05MB, 119.04 MB and 21 856.85MB)

ThanksEach of those files are probably smaller than the minimum M2TS size for reencoding. You call them "big", but when you have 25 files that combined add up to only 3.5GB on a 25GB backup -- it certainly isn't what I'd call big.

I'd leave the settings as-is, that's you best course of action. The minimum M2TS size is there to save you unnecessary reencoding time. But if you are determined to reencode 25 additional small files... you can always add a smaller MIN_M2TS_SIZE to your INI file (see HIDDENOPTS.TXT).

[Groucho2004]

@jdobbs
How do you check in BDRB if Avisynth is installed?
I didn't use the installer but Avisynth is certainly working and the registry entries for the plugin dir are there. Still, I get an error message when I start BDRB that Avisynth is not installed.

[jdobbs]

"Second Media Info shows the Proper file information for some reason BD Rebuilder does not include file 00872.m2ts in the encode."

I suppose he expected 00872.m2ts to be included and it was not.Yes, but sometimes (rarely) there are reasons why you don't want to include lead-in M2TS files in order to assure proper playback.

I'd like to know if there are issues in the movie-only playback. If not, then BD-RB made the right decision. I just don't want to waste time chasing something that was supposed to happen.

[jdobbs]

@jdobbs
How do you check in BDRB if Avisynth is installed?
I didn't use the installer but Avisynth is certainly working and the registry entries for the plugin dir are there. Still, I get an error message when I start BDRB that Avisynth is not installed.I get the version number directly from the DLL to see if it is the proper version. "2.5.8.0" should be an acceptable version -- for some reason the DLL you have (in System32) isn't matching "2.5.8.0" when it returns from the system call. There may be a hidden null character in there somewhere.

At startup BD-RB checks the registry for one of these two keys to see if it is installed:

HKLM\Software\AviSynth
HKLM\Software\Wow6432Node\AviSynth

[Groucho2004]

I get the version number directly from the DLL to see if it is the proper version. "2.5.8.0" should be an acceptable version -- for some reason the DLL you have (in System32) isn't matching "2.5.8.0" when it returns from the system call.
Figured it out. Your check expects the DLL to be in the system32 directory.

[jdobbs]

Figured it out. Your check expects the DLL to be in the system32 directory.If is wasn't there already... how did the string "2.5.8.0" get returned?

[Groucho2004]

If is wasn't there already... how did the string "2.5.8.0" get returned?
This is the error when avisynth.dll is not in the System32 directory:
http://s15.postimg.org/fsmd688hn/Image1.png

What's the reason for the restriction to that directory? When I load avisynth I use something like this:
HINSTANCE hDLL = ::LoadLibrary("avisynth");
if (!hDLL)
{
sMsg = "Failed to load avisynth.dll";
return FALSE;
}

It does not matter where avisynth.dll is as long as the "PATH" variable points to it.

[jdobbs]

This is the error when avisynth.dll is not in the System32 directory:
http://s15.postimg.org/fsmd688hn/Image1.png

What's the reason for the restriction to that directory? When I load avisynth I use something like this:
HINSTANCE hDLL = ::LoadLibrary("avisynth");
if (!hDLL)
{
sMsg = "Failed to load avisynth.dll";
return FALSE;
}

It does not matter where avisynth.dll is as long as the "PATH" variable points to it.That's where the installer puts the DLL. In other words, that's where it's supposed to be. I could always pull the path from the registry, I guess -- but then someone else would complain because the path has to be there. Why not just use the installer and avoid the problem?

[Groucho2004]

That's where the installer puts the DLL. In other words, that's where it's supposed to be.
Fair enough.

I could always pull the path from the registry, I guess
Which path?

[scotlandman]

@scotlandman

You've given me a lot of information -- but haven't told me what issue you are having??? Does it not play back correctly?

@jdobbs

Thank you for your reply and yes you are correct the file would not play as 3D as somehow the MVC smaller file of the two was not included by BD Rebuilder in the ReEncode.

It basically missed the 00872.m2ts file and only encoded the 00800.m2ts file. So would only playback as 2D.

I'm sorry if all my information was slightly missleading I just wanted to provide you with as much as possible, to allow you to see for comparison

I hope this helps you as I would love to use BD Rebuilder to make 3D BD25 movie only backup copies

Kind Regards

Scotlandman

[jdobbs]

@jdobbs

Thank you for your reply and yes you are correct the file would not play as 3D as somehow the MVC smaller file of the two was not included by BD Rebuilder in the ReEncode.

It basically missed the 00872.m2ts file and only encoded the 00800.m2ts file. So would only playback as 2D.

I'm sorry if all my information was slightly missleading I just wanted to provide you with as much as possible, to allow you to see for comparison

I hope this helps you as I would love to use BD Rebuilder to make 3D BD25 movie only backup copies

Kind Regards

ScotlandmanWhat you're saying would have no bearing upon whether or not it would play as 3D. The lead-in M2TS would have no effect in that way. The determination as to whether to play back the MVC dependent stream is provided by the MPLS.

Could you post your INI file (BDREBUILDER.INI located in the installation folder) -- what you posted is the INF file from that job, and it doesn't show your settings.

If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.

[Sharc]

@jdobbs
My videocam produces 1920x1080@25i (true interlaced 50 temporal shifted fields per second), which I IMPORT with BD-RB.

I tried Alternate Output, .mkv container 1280x720, wanting to keep it interlaced in order to preserve the temporal resolution of the original.

With Video Encoding Option "Resize 1920x1080 to 1280x720" disabled, the interlaced source gets directly resized without field separation, and then encoded as 1280x720@25i (MBAFF)

#Created by BD Rebuilder - v0.47.06 (beta)
LoadPlugin("C:\Program Files VIDEO\DGdecNV\DGDecodeNV.dll")
DGSource("C:\TEMP\BD REBUILDER\WORKFILES\VID_00000.DGI", fieldop=0)
Spline16Resize(1280,720)
LoadPlugin("C:\Program Files Video\BD_Rebuilder\tools\autocrop.dll")
Autocrop(mode=0)
ConvertToYV12().AssumeFPS(25000,1000)
Is this possibly a bug? Shouldn't the interlaced source be field separated, resized on field basis and weaved before encoding?

I know I can encode using "BD or AVCHD compliant structure" at 1920x1080@25i or 1440x1080@25i (MBAFF, TFF) in order to preserve the temporal resolution, however this seems not to work with Alternate Output 1280x720). Maybe I miss something?

[jdobbs]

Fair enough.


Which path?There's a SYSWOW64 path pointer in the registry for 64 bit systems, I'd have to check what exists for 32 bit.

In reality on a 64 bit system that's where the file physically exists after installation of the 32 bit application -- it is found via the redirector when you try to access it in system32. Why system32 is named "32" and holds 64 bit dlls is something only Microsoft could explain.

[jdobbs]

@jdobbs
My videocam produces 1920x1080@25i (true interlaced 50 temporal shifted fields per second), which I IMPORT with BD-RB.

I tried Alternate Output, .mkv container 1280x720, wanting to keep it interlaced in order to preserve the temporal resolution of the original.

With Video Encoding Option "Resize 1920x1080 to 1280x720" disabled, the interlaced source gets directly resized without field separation, and then encoded as 1280x720@25i (MBAFF)

#Created by BD Rebuilder - v0.47.06 (beta)
LoadPlugin("C:\Program Files VIDEO\DGdecNV\DGDecodeNV.dll")
DGSource("C:\TEMP\BD REBUILDER\WORKFILES\VID_00000.DGI", fieldop=0)
Spline16Resize(1280,720)
LoadPlugin("C:\Program Files Video\BD_Rebuilder\tools\autocrop.dll")
Autocrop(mode=0)
ConvertToYV12().AssumeFPS(25000,1000)
Is this possibly a bug? Shouldn't the interlaced source be field separated, resized on field basis and weaved before encoding?

I know I can encode using "BD or AVCHD compliant structure" at 1920x1080@25i or 1440x1080@25i (MBAFF, TFF) in order to preserve the temporal resolution, however this seems not to work with Alternate Output 1280x720). Maybe I miss something?Yes it should be field separated for resizing, I'll look at that. But you shouldn't expect interlaced output to 720 -- as that should be a progressive format. In reality it should probably be written as 1280x720@50fps to keep the temporal differences.

[Edit]
After further thought, I guess there's really no mandate to prevent output at 720i -- it's just a little odd I guess. I don't think it falls into any broadcast standard.

[scotlandman]

What you're saying would have no bearing upon whether or not it would play as 3D. The lead-in M2TS would have no effect in that way. The determination as to whether to play back the MVC dependent stream is provided by the MPLS.

Could you post your INI file (BDREBUILDER.INI located in the installation folder) -- what you posted is the INF file from that job, and it doesn't show your settings.

If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.

Hi jdobbs

Thanks for letting me know this I wasn't aware of this information.

Here is my BD Rebuilder INI file that I use for each Encode.

[Options]
VERSION=0.47.0.6
ENCODER=0
MODE=3
ENCODE_QUALITY=3
ONEPASS_ENCODING=0
AUTO_QUALITY=0
TARGET_SIZE=24400
PRIORITY_CLASS=2
BD25_SIZE=24400
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
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
AVCHD=1
REMOVE_WORKFILES=0
DGDECIM=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
USE_LAVF=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
DGDECNV=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=24400

I hope that this is helpful to you I am sorry if my previous attempts to give you information have not been helpful.

Kind Regards

Scotlandman

[jdobbs]

I hope that this is helpful to you I am sorry if my previous attempts to give you information have not been helpful.No need to be sorry... I appreciate the information.

[Groucho2004]

There's a SYSWOW64 path pointer in the registry for 64 bit systems, I'd have to check what exists for 32 bit.
I find it easy and safe to retrieve this information through environment variables. For example, if "PROGRAMFILES(X86)" is defined, you're on a 64 Bit OS. On a 64 Bit system, "WINDIR" + "\system32" and "WINDIR" + "\SysWOW64" are the system directories.

Why system32 is named "32" and holds 64 bit dlls is something only Microsoft could explain.
This (http://www.viva64.com/en/k/0028/) is probably the reason.

[scotlandman]

No need to be sorry... I appreciate the information.

Thank you very much for your kind comments.

Just for further information I do not know if it is at all relevant.

I am running Windows 8.1 Pro in bootcamp in a new MAC Pro 6core 32GB RAM 1TB Flash memory Dual D700GPU

It is pretty awesome for your software as even in 2 pass Very slow completes in 3 hours few minutes

I just wandered if OS had any bearing on the result.

Thanks

[Cedvano]

Each of those files are probably smaller than the minimum M2TS size for reencoding. You call them "big", but when you have 25 files that combined add up to only 3.5GB on a 25GB backup -- it certainly isn't what I'd call big.

I'd leave the settings as-is, that's you best course of action. The minimum M2TS size is there to save you unnecessary reencoding time. But if you are determined to reencode 25 additional small files... you can always add a smaller MIN_M2TS_SIZE to your INI file (see HIDDENOPTS.TXT).

I have put MIN M2TS and MIN MPLS in 0 or 1 and no more effect.
The bonus take +/- 200 MB / file

General
ID : 0 (0x0)
Complete name : D:\Final_Destination_4_3D\BDMV\STREAM\00001.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 266 MiB
Duration : 3mn 12s
Overall bit rate mode : Variable
Overall bit rate : 11.6 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 3mn 12s
Bit rate : 10.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Bottom Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.176
Stream size : 250 MiB (94%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Format profile : Dolby Digital
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 3mn 12s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 4.40 MiB (2%)

Text #1
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #2
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #3
ID : 4610 (0x1202)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #4
ID : 4611 (0x1203)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #5
ID : 4612 (0x1204)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #6
ID : 4613 (0x1205)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Text #7
ID : 4614 (0x1206)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 3mn 6s
Delay relative to video : 2s 269ms

Mediainfo on 1 file.

[Sharc]

Yes it should be field separated for resizing, I'll look at that. But you shouldn't expect interlaced output to 720 -- as that should be a progressive format. In reality it should probably be written as 1280x720@50fps to keep the temporal differences.

[Edit]
After further thought, I guess there's really no mandate to prevent output at 720i -- it's just a little odd I guess. I don't think it falls into any broadcast standard.
Yes, you are right, 1280x720p@50fps (bobbed) for keeping the temporal differences would probably be closer to any standard. Temporal smoothness should outweigh the bob shimmer, I believe.

[jdobbs]

I find it easy and safe to retrieve this information through environment variables. For example, if "PROGRAMFILES(X86)" is defined, you're on a 64 Bit OS. On a 64 Bit system, "WINDIR" + "\system32" and "WINDIR" + "\SysWOW64" are the system directories.I just look for "ProgramW6432" -- if it is there then the O/S is 64 bit, otherwise it is 32 bit.This (http://www.viva64.com/en/k/0028/) is probably the reason.I was just throwing a cheap shot at Microsoft... I knew why they did it -- it's just counterintuitive, like so many things they do.

[AmigaFuture]

Update for Cloud Atlas chapters.. I bought an SSD and...reinstalled Windows 7, and the Chapters are okay now. I still have the SATA drive, so I'll check into it. I thought you might like an update.

[jdobbs]

Update for Cloud Atlas chapters.. I bought an SSD and...reinstalled Windows 7, and the Chapters are okay now. I still have the SATA drive, so I'll check into it. I thought you might like an update.Thanks.

[jdobbs]

@scotlandman
If the 00872.MPLS is the MVC portion of the playback -- then it wouldn't show up anyway except in the demuxing. But I don't know whether that is what is even what is being reported by MediaInfo.I picked up this disc and am running it. I was correct in assuming 00872 was the MVC portion of the disc. So it wouldn't show in the "Streams" list of BD-RB (as that M2TS is only the dependent view that is associated with 00895.M2TS). So it isn't "missing", as it shouldn't be there.

The job is currently running -- I will post results when it completes (it will likely be several hours).

I'm a little worried that while you said you are using the US version of the disc for which you sent me a link (http://www.amazon.com/Marvels-Avengers-Four-Disc-Combo-Download/dp/B001KVZ6HK/ref=sr_1_1?s=movies-tv&ie=UTF8&qid=1400190566&sr=1-1&keywords=marvels+avengers+3d) -- your encode's log referenced 00800.M2TS as if it were the file associated with MPLS 00800... but in the commercial disc I am encoding the proper M2TS is 00895, there isn't even a 00800.M2TS on the 3D disc (it only exists on the 2D disc that is included in the 4 disc package)...
[05/16/14] BD Rebuilder v0.47.07 (beta)
[18:06:32] Source: MARVELS_THE_AVENGERS_3D_00800
- Input BD size: 41.83 GB
- Approximate total content: [02:22:54.899]
- Target BD size: 23.83 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: Highest (Very Slow), ABR
- MVC 3D Output Mode enabled
- Decoding/Frame serving: FRIMDecode
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[18:06:33] PHASE ONE, Encoding
- [18:06:33] Processing: VID_00895 (1 of 1)
- [18:06:33] Extracting A/V streams [VID_00895]
- [18:16:39] Reencoding video [VID_00895]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 205,592 frames
- Bitrate: 16,404 Kbs
- Using FRIMEncoder for MVC encoding
- [18:16:39] Reencoding: VID_00895, Pass 1 of 1
Are you positive you are using the original 3D disc and it was not pre-processed in any way? I'd hate to think I just threw away $40 (which I can't afford with my limited donations) on a wild goose chase.

[Edit]

The encode just completed. I used the INI settings provided, so the encode used all the settings exactly as reported. This included the "Highest (Very Slow)" setting which extended my encode time to 16 hours. The bottom line is that it completed with no issues, no problems were found when I examined the result, and the movie-only backup plays in 3D exactly as it should.

[Lathe]

Borders are added to make it compliant. But it isn't done during the import, it is done when processing the imported source. If you look in the BDMV/STREAM folder of the import (the pseudo-BD source) you'll see a file with the extension .ADJ. This holds any adjustments that needs to be made to the source. It is a text file and is made up of AVISYNTH functions (like AddBorders()).

Please forgive me for quoting an older post, but to keep it brief, I did import a 'cropped' MKV file (2.40:1 I believe) and after processing, MediaInfo showed the resulting m2ts file to be the same (not 16x9)

Did I miss something?

Thank you JDobbs for a most excellent program; when I am able, I will definitely send you some funds :)

[jdobbs]

Please forgive me for quoting an older post, but to keep it brief, I did import a 'cropped' MKV file (2.40:1 I believe) and after processing, MediaInfo showed the resulting m2ts file to be the same (not 16x9)

Did I miss something?

Thank you JDobbs for a most excellent program; when I am able, I will definitely send you some funds :)The import will not correct anything -- that's why the result is called a pseudo-BD. The corrections are made when the disc is re-encoded using the pseudo-BD as its source. You will find a folder called PSEUDO in the import folder. It contains the filters that will add borders, resize, or make audio adjustments to make the disc compliant.

The only time you can burn an imported folder to disc without re-encoding is if the source was 100% BD compliant -- and that is very rare.

I've done many imports from MKV in testing -- and BD-RB has always correctly for me.

[Lathe]

The import will not correct anything -- that's why the result is called a pseudo-BD. The corrections are made when the disc is re-encoded using the pseudo-BD as its source. You will find a folder called PSEUDO in the import folder. It contains the filters that will add borders, resize, or make audio adjustments to make the disc compliant.

The only time you can burn an imported folder to disc without re-encoding is if the source was 100% BD compliant -- and that is very rare.

I've done many imports from MKV in testing -- and BD-RB has always correctly for me.

Thank you, but AFTER the full re-encode, shouldn't the resulting BDMV folder (stream/m2ts) be fully compliant? If so, why would after re-encoding MediaInfo show the resulting m2ts still to be 2.40:1...? Shouldn't the 'missing borders' be replaced once it is done re-encoding?


Here was the exchange that SEEMED to say 'Yes' about this:

ABADDON:

When using the new "Import" feature, and subsequently fully processing, will a video be "uncropped" to restore the compliant resolution (by adding black boarders) if necessary, or simply vertically stretched?
__________________

Last edited by abbadon; 1st October 2012 at 18:21.


omegaman7's Avatar

Quote:

Originally Posted by abbadon View Post
When using the new "Import" feature, and subsequently fully processing, will a video be "uncropped" to restore the compliant resolution (by adding black boarders) if necessary, or simply vertically stretched?

I ran a cropped video recently. Clearly black borders were added in. It came out perfectly
__________________



abbadon

hmmm, that's what I figured was SUPPOSED to happen, but for some reason I keep getting stretch video instead of borders . It's just import and process, right? No extra/hidden options? I'm sure I'm missing something...



That is why I believe I am missing something :)

Appreciate your time!

[jdobbs]

Thank you, but AFTER the full re-encode, shouldn't the resulting BDMV folder (stream/m2ts) be fully compliant? If so, why would after re-encoding MediaInfo show the resulting m2ts still to be 2.40:1...? Shouldn't the 'missing borders' be replaced once it is done re-encoding?

Appreciate your time!Yes they should be replaced. The result should be 1920x1080, 1280x720, or 720x480/576. The film itself, of course, will still be 2.40:1 -- but with borders to bring it to the compliant size.

If you look at the .AVS file for the video during the encoding you should see the AVISYNTH filtering that adds the border.

[mparade]

Thank you JDobbs for a most excellent program; when I am able, I will definitely send you some funds :)[/QUOTE]

Next week, I am going to send you a little bit more than I usually do, too. (because it seems that wasting money on wild goose chasing has become one of your favorite pastime:))

Thank you very much for the World's best ever BD backup software.

[Lathe]

Yes they should be replaced. The result should be 1920x1080, 1280x720, or 720x480/576. The film itself, of course, will still be 2.40:1 -- but with borders to bring it to the compliant size.

If you look at the .AVS file for the video during the encoding you should see the AVISYNTH filtering that adds the border.

Hmmm, but it isn't...

Please note the added reference of the original question above, if you don't mind.

The re-encoded m2ts file still shows as 2.40:1

Notice ABADDON's similar comment above, that in his case too, the black borders were NOT re-introduced. However OMEGAMAN said that he also imported a 'cropped' MKV file into BDRB and in his case it DID work!

Just trying to see if there is something that I'm missing. If there is no evident answer, I don't mean to use up too much of your time pestering you with this.

Thank you very much though!

[omegaman7]

All MKV files with cropped black borders, were reintroduced after encoding. If I were you, I would take a look at the .inf file within the PSEUDO folder. That may shed some light on the subject ;)

[Lathe]

All MKV files with cropped black borders, were reintroduced after encoding. If I were you, I would take a look at the .inf file within the PSEUDO folder. That may shed some light on the subject ;)

Heh, thanks Omegaman; you were actually one of the ones that I was quoting above. You were the one who said that it DID work.

It's funny; it's like I keep missing the point here apparently. Everyone is telling me to look at this file here and there (which I will indeed try to do) But, it's like... the question that Abaddon asked and you answered quoted above. He asked the exact same thing I'm asking and said that his resulting file was 'stretched'. You however said that you imported 'cropped' MKV files (which is what I did too) and yet for you the resulting BDMV folder (m2ts) was properly re-encoded with borders and I assume would have read as 16x9 with MediaInfo.

I'll go and check those files, but I don't know if I am smart enough to figure out the answer :)

Heh, it would be nice just to know, 'Does it do it, or doesn't it?' And, what is funny that per your guys conversation, you both say opposite things...

Maybe I should learn what the simple Avisynth code is for adding the black borders and just add it to BDRB, telling it to do that; I don't know...

Well, I've bothered you nice people quite enough about this; I will endeavor to read and research more myself.

Thanks guys!

[Lathe]

Heh, I looked at the .ini in the PSEUDO folder and it very clearly says 'add borders' :)

Soooo, am I to conclude from this that the re-encoded file, although MediaInfo SAYS that it is 2.40:1, that when I play it, somehow it WILL have the black borders re-introduced?

This would be great because then BDRB, a FAR superiour program can replace the 'Uncrop' feature in the very outdated MultiAVCHD.

Thanks again!

[AmigaFuture]

When BD-RB has Imported, then created the PSEUDO directory...now, be sure "Full Backup" is selected or "Movie & Menus" are selected. Then BD-25 or 50 output. Then click "Backup". Your resulting movie should have the borders added making it 1920x1080 as Jdobbs typed. Don't just rely on the Imported created PSEUDO directory. Also, make sure all resizing is disabled.

[Lathe]

When BD-RB has Imported, then created the PSEUDO directory...now, be sure "Full Backup" is selected or "Movie & Menus" are selected. Then BD-25 or 50 output. Then click "Backup". Your resulting movie should have the borders added making it 1920x1080 as Jdobbs typed. Don't just rely on the Imported created PSEUDO directory. Also, make sure all resizing is disabled.

Thank you most kindly AmigaFuture; you are always so nice :)

You know, that is what I'm pretty SURE that I did. I think that I'd better go through it again and see if maybe I missed or changed some steps, because my resulting file is not being read that way despite the fact that the PSEUDO folder says that it will add '140' to top and bottom. And it definitely re-encoded with 2 passes set at High Quality (took about 3 1/2 to 4 hrs altogether and amusingly filled out the full BD-25 even though the original MKV file was about 13 Gigs :)

Thanks again!

[Lathe]

AH, I think you hit on it AmigaFuture!

I went back to BDRB with the PSEUDO directory as it's source, where I left off from last time, and I DID notice that the back up mode was STILL set at 'Quick-Play'!!! I don't think that I had then reset the mode back to 'Full Backup'! I'm doing that right now to a different output folder.

Thank you SO much! I'm thinking that that must be it because no one had specifically stated that yet, although logically, I really should have figured that out since that part of the importing was already done, and then logically I would be doing a 'Normal' back up after that using the imported folder as the source :)

Cheers!

[omegaman7]

Glad you got er figured Lathe ;)

[AmigaFuture]

I view that as testing so I'd use the High-Speed (BD25+) for testing...since it's......High-Speed. ;-) It can also be done with Alternate Output, just select MKV/MP4 1920x1080 as the video size. Being sure to uncheck the Borders setting. :D I'd wish you luck, but in my experiences luck doesn't exist. So, have fun...and you're welcome. :D

[Lathe]

Glad you got er figured Lathe ;)

Yes, thanks guys; I REALLY appreciate it when the ones here help with their experience and input! :)

[krassle]

Hi jdobbs, I'm doing simple non-3D movie-only encodes for avchd(bd5/9) and recently switched from 4415 to 4706. I noticed the tsmuxer version change, for better 3D support I guess, but I'm not quite happy with it. Because I also use multiAVCHD and it does not support newer versions of tsmuxer, I have to manually remux now.
So, if I were to swap the new version(2.6.12) for the old one or just use 'TSMUXER=C:\path2old\file', would this break things in BDRebuilder?
Would it be possible to have the old version of tsmuxer(1.10.6) for non-3D-sources as an alternative?

THANKS FOR YOUR GREAT EFFORT!

Cheers,

Gesendet von meinem Nexus 7 mit Tapatalk

[jdobbs]

Hi jdobbs, I'm doing simple non-3D movie-only encodes for avchd(bd5/9) and recently switched from 4415 to 4706. I noticed the tsmuxer version change, for better 3D support I guess, but I'm not quite happy with it. Because I also use multiAVCHD and it does not support newer versions of tsmuxer, I have to manually remux now.
So, if I were to swap the new version(2.6.12) for the old one or just use 'TSMUXER=C:\path2old\file', would this break things in BDRebuilder?
Would it be possible to have the old version of tsmuxer(1.10.6) for non-3D-sources as an alternative?

THANKS FOR YOUR GREAT EFFORT!

Cheers,

Gesendet von meinem Nexus 7 mit TapatalkYes it will break things. There are several other new enhancements (such as DTS-Express support) that BD-RB uses now (beyond the 3D enhancements). Unfortunately your problem is with multiAVCHD's lack of support -- not BD-RB.

I can think of no reason why you couldn't use v1.10.6 with multiAVCHD while keeping the new one (v2.6.12) for BD-RB. BD-RB uses the one in its TOOLS folder by default.

[1Bullet]

I don't really consider this a Bug but more as nuisance problem.
Most time when using BD rebuilder I select it to convert DTS MA to DD 5.1 at 640 kb which is fine.
Issue is when DTS MA is 2 channel audio, BDRB converts audio a very small DD 2.1 file which is to be expected.
My fix now is to run the stream though tsMuxer first and down convert from DTS-HD to DTS core.
Then select leave Audio untouched in BD rebuilder.
This mainly applies to older movies, maybe this is now a request, is there anyway to have BDRB downconvert DTS-MA to DTS core rather than converting it to DD 5.1?

[worknstiff]

[@ 1Bullet RE:is there anyway to have BDRB downconvert DTS-MA to DTS core rather than converting it to DD 5.1?[/QUOTE]

If I am not mistaken all you have to do is go to Setting and then Setup and take the Check out of Keep HD Audio Intact and leave the check in Do Not Convert DTS to AC3. I think this will let it keep DTS at 1500kbps instead of encoding it to DD 640. Of course this is for BD output only. Hope this is what happens. I think that's how I have been doing it.

[Starfiresg1]

I've recently turned on the option to use internal LAVF for frame serving. I've encountered an issue with resizing to 1440 which is not present using DirectShow.
When I choose to resize to 1440x1080 both (LAVF and Directshow) generate an output with 1440x1080. If LAVF is used the display aspect ratio seems to be wrong at 4:3 - the generated disc doesn't use the full screen for playback and the picture is clearly squeezed horizontally. Mediainfo shows a "Display Aspect Ratio" of 4:3 on the resulting m2ts. Encoding the same source with DirectShow used for Frameserving produces an output that correctly display as 16:9 during playback - Mediainfo shows a "Display Aspect Ratio" of 16:9. The result is independent of specific discs and can also be reproduced with small Full-HD-Imports for Quick Testing.

Both generate the same AVS script:
#Created by BD Rebuilder - v0.47.06 (beta)
DirectshowSource("K:\BR-TEMP\IMPORTS\00110\BDMV\STREAM\00000.m2ts", fps=24, framecount=5573, audio=false)
BicubicResize(1440,1080)
ConvertToYV12().AssumeFPS(24000,1000)

The encoding command line is different (taken from LASTCMD.txt):
LAVF
"G:\Program Files (x86)\BD-Rebuilder\tools\x264-64.exe" "K:\BR-TEMP\IMPORTS\00110\BDMV\STREAM\00000.m2ts" --preset superfast --bluray-compat --demuxer lavf --fps 24 --no-interlaced --video-filter resize:width=1440,height=1080,sar=1:1,method=bicubic --b-pyramid none --weightp 1 --qpmin=0 --bitrate 15000 --level 4.1 --sar 4:3 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 13000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 15000 --threads auto --slices 4 --thread-input --output "K:\BR-TEMP\WORKFILES\00000.m2ts.264"
Directshow
"G:\Program Files (x86)\BD-Rebuilder\tools\x264.exe" "K:\BR-TEMP\WORKFILES\VID_00000.AVS" --preset superfast --bluray-compat --b-pyramid none --weightp 1 --qpmin=0 --bitrate 15000 --level 4.1 --sar 4:3 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 13000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 15000 --threads auto --slices 4 --thread-input --output "K:\BR-TEMP\WORKFILES\VID_00000.AVS.264"

Settings used
[Options]
VERSION=0.47.0.6
MODE=0
ENCODE_QUALITY=0
ONEPASS_ENCODING=2
AUTO_QUALITY=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=1
RESIZE_720=0
DEINTERLACE=1
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=0
AVCHD=1
REMOVE_WORKFILES=0
MOVIE_ONLY_LOOP=1
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
USE_LAVF=1
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
UNMASK_CHAPTER=0
COMPLETION_BEEP=0
DGDECNV=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=1
CUSTOM_TARGET_SIZE=500
ENABLE_TEST=1
ENABLE_BLANKING=1
FORCED_SUB_LANG=eng;
ENCODER=0
DGDECIM=0
FRIMSOURCE=0

[scotlandman]

@scotlandman
I picked up this disc and am running it. I was correct in assuming 00872 was the MVC portion of the disc. So it wouldn't show in the "Streams" list of BD-RB (as that M2TS is only the dependent view that is associated with 00895.M2TS). So it isn't "missing", as it shouldn't be there.

The job is currently running -- I will post results when it completes (it will likely be several hours).

I'm a little worried that while you said you are using the US version of the disc for which you sent me a link (http://www.amazon.com/Marvels-Avengers-Four-Disc-Combo-Download/dp/B001KVZ6HK/ref=sr_1_1?s=movies-tv&ie=UTF8&qid=1400190566&sr=1-1&keywords=marvels+avengers+3d) -- your encode's log referenced 00800.M2TS as if it were the file associated with MPLS 00800... but in the commercial disc I am encoding the proper M2TS is 00895, there isn't even a 00800.M2TS on the 3D disc (it only exists on the 2D disc that is included in the 4 disc package)...
[05/16/14] BD Rebuilder v0.47.07 (beta)
[18:06:32] Source: MARVELS_THE_AVENGERS_3D_00800
- Input BD size: 41.83 GB
- Approximate total content: [02:22:54.899]
- Target BD size: 23.83 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: Highest (Very Slow), ABR
- MVC 3D Output Mode enabled
- Decoding/Frame serving: FRIMDecode
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[18:06:33] PHASE ONE, Encoding
- [18:06:33] Processing: VID_00895 (1 of 1)
- [18:06:33] Extracting A/V streams [VID_00895]
- [18:16:39] Reencoding video [VID_00895]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 205,592 frames
- Bitrate: 16,404 Kbs
- Using FRIMEncoder for MVC encoding
- [18:16:39] Reencoding: VID_00895, Pass 1 of 1
Are you positive you are using the original 3D disc and it was not pre-processed in any way? I'd hate to think I just threw away $40 (which I can't afford with my limited donations) on a wild goose chase.

[Edit]

The encode just completed. I used the INI settings provided, so the encode used all the settings exactly as reported. This included the "Highest (Very Slow)" setting which extended my encode time to 16 hours. The bottom line is that it completed with no issues, no problems were found when I examined the result, and the movie-only backup plays in 3D exactly as it should.

@jdobbs

Sorry for the late reply I have not been on the forum since yesterday morning.
I have checked my side and it would seem that there has been a slight mistake when I converted using Anydvd hd I converted Rip dvd to harddisk instead of Rip to image. I'm wandering if somehow this has caused the discrepancy with my file format.

I would also like to say sorry for your time taken to find this out and for any inconvenience to yourself as I understand that your time is very valuable to you and you resolve numerous problems/issues for people every day. As a result of your financial costs I have made a donation of $80 via your Paypal Transaction ID:9BU13049NV1728529. This should cover the cost of the 4 disc box set and the same again towards your ongoing costs.

Please accept my sincere apologies and gratitude for your time taken and efforts to accommodate me. This was my first attempt at using the software for 3D ReEncode, And it is a learning curve all be it one which seems could have been avoided.

I will double check and check again before making any further posts in the future.

Kind Regards

Scotlandman

[jdobbs]

I don't really consider this a Bug but more as nuisance problem.
Most time when using BD rebuilder I select it to convert DTS MA to DD 5.1 at 640 kb which is fine.
Issue is when DTS MA is 2 channel audio, BDRB converts audio a very small DD 2.1 file which is to be expected.
My fix now is to run the stream though tsMuxer first and down convert from DTS-HD to DTS core.
Then select leave Audio untouched in BD rebuilder.
This mainly applies to older movies, maybe this is now a request, is there anyway to have BDRB downconvert DTS-MA to DTS core rather than converting it to DD 5.1?If you say "Don't convert to AC3" but don't say "Keep HD" you should get the core as a result.

[jdobbs]

I've recently turned on the option to use internal LAVF for frame serving. I've encountered an issue with resizing to 1440 which is not present using DirectShow.
When I choose to resize to 1440x1080 both (LAVF and Directshow) generate an output with 1440x1080. If LAVF is used the display aspect ratio seems to be wrong at 4:3 - the generated disc doesn't use the full screen for playback and the picture is clearly squeezed horizontally. Mediainfo shows a "Display Aspect Ratio" of 4:3 on the resulting m2ts. Encoding the same source with DirectShow used for Frameserving produces an output that correctly display as 16:9 during playback - Mediainfo shows a "Display Aspect Ratio" of 16:9. The result is independent of specific discs and can also be reproduced with small Full-HD-Imports for Quick Testing.

Both generate the same AVS script:


The encoding command line is different (taken from LASTCMD.txt):
LAVF

Directshow


Settings usedI just added resizing from within X264/LAVF a few versions back. Before then all resizing was forced to be encoded via AVISYNTH. So it's likely that I missed something in the change. I'll take a look at it.