BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Yes (same as DivX).

Edit:
Captures to x264 AVC lossless (format profile High 4:4:4 Predictive@L3) can be imported without conversion. I tested it with x264vfw which is available from Komisar or MasterNobody.If you want to keep the conversion lossless you can always set IMPORT_CONVERT_CRF=0 in your INI. Of course it will make the pseudo-BD structure pretty big in your IMPORT folder.

[Sharc]

If you want to keep the conversion lossless you can always set IMPORT_CONVERT_CRF=0 in your INI. Of course it will make the pseudo-BD structure pretty big in your IMPORT folder.
Good point. This will reduce the lossy conversion to the final reencoding step. The size of the intermediate import file shouldn't matter as the video clips are normally short.

[colinhunt]

Which Hobbit? I have Hobbit, Desolation of Smaug, 3D (bought for a bug report) -- any chance that's the one?
The first movie in the trilogy, An Unexpected Journey. Extended version of that, in fact.

Are you absolutely positive they are reversed?
100% certain. Burned output to disc, played on an Oppo player connected to a 3D projector. Verified reversal by viewing movie and reversing glasses to see proper depth.

It's not something left over from a previous attempt?
Nope, I've deleted all .iso files created on 05020 and earlier versions so there's no change of a mix-up.

Outline exactly what you're doing and also provide the log and INI contents -- and I'll look at it. Also make sure you mention any "tweaking" you may be doing with other tools.
1) Created an .iso image of the Hobbit disc 2 using last version of AnyDVD HD
2) Mounted .iso image in Windows 10 using its internal image mounter
3) Opened drive letter H: (i.e. the mounted .iso) on BD-RB 05021
4) Selected "Movie-Only Backup"
5) Disc has two playlists: 00100 with 16 chapters and 00960 with 1 chapter. BD-RB chose the correct one (00100) automatically
6) BD-RB tends to make undersized outputs of 3D movie-only backups when target is set to BD-25 so I used a Custom Target Size of 24300MB
7) Ran backup, burned resulting .iso on disc, tested output as described above

Note: I have checked the .iso image created in step 1 and verified views are not reversed in it. As for tweaks, I can think of nothing else besides the custom target size.

LOG
[01/24/17] BD Rebuilder v0.50.21
[20:44:15] Source: HOBBIT_EXT_PT1_D2_00100
- Input BD size: 27.62 GB
- Approximate total content: [01:23:28.378]
- Target BD size: 23.73 GB
- Windows Version: 6.2 [9200]
- MOVIE-ONLY mode enabled
- Quality: Highest (Very Slow), ABR
- Output folder: Q:\_ENCODES\
- MVC 3D Output Mode enabled
- Decoding/Frame serving: FRIMDecode
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
[20:44:17] PHASE ONE, Encoding
- [20:44:17] Processing: VID_00006 (1 of 1)
- [20:44:17] Extracting A/V streams [VID_00006]
- [20:58:47] Reencoding video [VID_00006]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 120,081 frames
- Bitrate: 31,442 Kbs
- Using FRIMEncoder for MVC encoding
- [20:58:47] Reencoding: VID_00006, Pass 1 of 1
- [21:36:37] Video Encode complete
- [21:36:38] Processing audio tracks
- Track 4352 (eng): Keeping original audio
[21:36:38]PHASE ONE complete
[21:36:38]PHASE TWO - Rebuild Started
- [21:36:38] Rebuilding BD-3D file Structure
[21:42:24] - Encode and Rebuild complete
[21:42:24] JOB: HOBBIT_EXT_PT1_D2 finished.

INI
[Options]
VERSION=0.50.0.21
ENCODER=0
MODE=3
OUTPUT_FOLDER=Q:\_ENCODES
ENCODE_QUALITY=3
QUALITY_ULTRA=1
FRIM_SW_DECODE=0
FRIM_SW_ENCODE=0
OUTPUT_3D_ISO=1
IGNORE_3D=0
ONEPASS_ENCODING=0
AUTO_QUALITY=0
TARGET_SIZE=25300
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=0
AC3_192=0
KEEP_HD_AUDIO=1
AUDIO_DRC=0
DECODER=4
AVCHD=1
REMOVE_WORKFILES=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=1
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
PGSTOSRT=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=24800
[Paths]
SOURCE_PATH=I:\
WORKING_PATH=F:\_BDRB_OUTPUT\

Note wrt to .INI: I've changed target size since running the Hobbit backup which is why the size above differs from the 24300MB I used for Hobbit. I've made no other changes to any BD-RB setting since running the Hobbit backup.

[colinhunt]

jdobbs, didn't BD-RB use to have a hidden option for setting whether it would create the SSIF directory or, alternatively, stereo .m2ts files (i.e. no SSIF directory) when making Full Disc backups of 3D titles?

I thought I'd try to make a Full Disc Backup of Hobbit disc 2 and use other tools to create an .iso image file from the STREAM + STREAM/SSIF directory structure, but the Backup does not have SSIF. Instead, .m2ts files have two video streams, and I can't seem to find that "SSIF or stereo m2ts" option anymore.

update: Played the Full Disc backup's main movie stereo .m2ts on Stereoscopic Player, and had to use player's "swap views" button to correct for reversed L/R views. I'll burn the data on disc to verify on Oppo + 3D projector combo.

[Sharc]

jdobbs, didn't BD-RB use to have a hidden option for setting whether it would create the SSIF directory or, alternatively, stereo .m2ts files (i.e. no SSIF directory) when making Full Disc backups of 3D titles?

I thought I'd try to make a Full Disc Backup of Hobbit disc 2 and use other tools to create an .iso image file from the STREAM + STREAM/SSIF directory structure, but the Backup does not have SSIF. Instead, .m2ts files have two video streams, and I can't seem to find that "SSIF or stereo m2ts" option anymore.
Colin:
From the HIDDENOPTS.TXT
OUTPUT_3D_ISO=n n = 0/1 - 0=Off (default) - if set to "1", movie-only output is to an ISO rather than a folder

and from the CHANGES.TXT
April 7th, 2014 - v0.47.04
- Implemented 3D Full Backup Mode. Note that
BD-RB converts 3D method so that the SSIF
folder is no longer required -- the method
is 100% compliant with the BD standard.
(v0.47.03)
- Due to the changes in the way 3D is handled,
BD-RB no longer outputs to ISO by default on
movie-only 3D encodes. It can be enabled by
using the OUTPUT_3D_ISO hidden option. Note:
This option only applies to movie-only 3D
encodes. (v0.47.03)

[colinhunt]

Colin:
From the HIDDENOPTS.TXT
OUTPUT_3D_ISO=n n = 0/1 - 0=Off (default) - if set to "1", movie-only output is to an ISO rather than a folder

and from the CHANGES.TXT
That's not the hidden option I was asking about.

[Sharc]

That's not the hidden option I was asking about.
Output to ISO means the ISO will contain the SSIF structure. It works for movie-only though, not for full backups IIRC.

[colinhunt]

Output to ISO means the ISO will contain the SSIF structure. It works for movie-only though, not for full backups IIRC.
Yes, I know. But unless my memory totally fails, I'm fairly certain that at some in the past it was possible to make Full Disc backups where BD-RB output Blu-ray directory structure (i.e. not .iso) that contained the SSIF directory. And also that it was possible to use a hidden option to change that so that instead of outputting SSIF, BD-RB created "in-mux" m2ts files that had both views in them as two separate video streams.

edit: Found it in Changes.txt:

- Made in-mux (single M2TS) 3D multiplexing
mode the default on full-backup 3D. This
can be changed back with the hidden option
FORCE_INMUX_3D=0.

[colinhunt]

jdobbs, I'm happy to report that the L/R views are not reversed on Hobbit's Full Disc backup containing in-muxed stereo .m2ts files. I was actually surprised that my ancient Oppo Blu-ray player had no issues with in-muxed stereo files. I know they are supposedly 100% compliant with the BD spec but I've always suspected it's one of those features that is not mandatory and hence not supported by all manufacturers.

Despite this success I'd still prefer to be able to make movie-only .iso backups that don't have their views reversed. For example, this Hobbit disc has several GBs worth of unnecessary data on it that only serves to lower the bitrate of the main feature when present on the same BD-25 backup.

[jdobbs]

I know they are supposedly 100% compliant with the BD spec but I've always suspected it's one of those features that is not mandatory and hence not supported by all manufacturers.In-mux is not "supposedly" anything. I know what I'm doing, and when I say it is 100% compliant -- it is 100% compliant. Support is required by the spec -- so if there is a 3D player out there that doesn't support it THE PLAYER IS NOT COMPLIANT. It is used on many commercial discs. Frankly I think the SSIF format is ridiculous (with its faux appearance of two files that really only exists due to exotic use of sector pointers) and can see no good reason why it is used. I think it's just there to make copying difficult.

Can you send me the MPLS of the playlist that is reversed?

[colinhunt]

In-mux is not "supposedly" anything. I know what I'm doing, and when I say it is 100% compliant -- it is 100% compliant. Support is required by the spec -- so if there is a 3D player out there that doesn't support it THE PLAYER IS NOT COMPLIANT.
Apologies, I did not mean it like that. I was referring to the fact that the spec contains also optional, non-mandatory features that are not supported by all manufacturers. I have no idea whether in-mux stereo is a mandatory or an optional feature.

Frankly I think the SSIF format is ridiculous
Agreed.

Can you send me the MPLS of the playlist that is reversed?
Sure thing!

[jdobbs]

Apologies, I did not mean it like that. I was referring to the fact that the spec contains also optional, non-mandatory features that are not supported by all manufacturers. I have no idea whether in-mux stereo is a mandatory or an optional feature.


Agreed.


Sure thing!I looked at the MPLS. It is in the standard format in which the left view is in the main stream (AVC) portion of the video. So it shouldn't need to be swapped. I'll look at it and make sure I didn't screw up the standard configuration by trying to account for the unusual.

[colinhunt]

I looked at the MPLS. It is in the standard format in which the left view is in the main stream (AVC) portion of the video. So it shouldn't need to be swapped. I'll look at it and make sure I didn't screw up the standard configuration by trying to account for the unusual.
Wait. I sent you the playlist from the movie-only backup that had its views reversed. Did you want the original's playlist instead? /confused

[jdobbs]

Wait. I sent you the playlist from the movie-only backup that had its views reversed. Did you want the original's playlist instead? /confusedYes. Also, can you send me the .meta file from the working folder?

[colinhunt]

Yes. Also, can you send me the .meta file from the working folder?
I've run a few backups since the Hobbit so it's probably gone. I'll run Hobbit again using same settings.

[jdobbs]

I've run a few backups since the Hobbit so it's probably gone. I'll run Hobbit again using same settings.Wrong meta file. I need the one entitled MUX_MOVIE_ONLY.meta. I should have been clearer.

[jdobbs]

@colinhunt

I just did several tests with 3D sources and output to ISO. It worked correctly every time. I'll look at it some more -- but it sure looks like it's working from here.

[Edit] Never mind. I was able to repeat it. I traced it and I see how it happens now. I'll get a fix in for the next release.

[colinhunt]

@colinhunt
[Edit] Never mind. I was able to repeat it. I traced it and I see how it happens now. I'll get a fix in for the next release.
Fantastic, thank you!

[Lathe]

Aww yeah - thank you! I'll start running tests immediately. Y'know, this might merit another donation from yours truly...

Whadaya mean 'Might'...??? :devil:

Pay the man... http://lathe-of-heaven.com/club.gif

[colinhunt]

Whadaya mean 'Might'...??? :devil:
I've donated several times over the years. jdobbs even told me once not to donate again, but I'm guessing he was seriously distracted at the moment :D

Regardless, I was planning on donating when the movie-only 3D backup bug was squashed.

[Lathe]

I've donated several times over the years. jdobbs even told me once not to donate again, but I'm guessing he was seriously distracted at the moment :D

Regardless, I was planning on donating when the movie-only 3D backup bug was squashed.

Good man! http://lathe-of-heaven.com/yes.gif

Yes, I actually do remember that...

[jdobbs]

I have updated the first post of this thread with a link to the latest version of BD-RB (v0.50.22). Changes for this release:- Added three more supported CODECs to the
import capability (HFYU, LAGS, and ULY2).
Automatic conversion to AVC will occur
during import.
- Made changes to the way VFR is handled
on import. Now it is converted, during
import, to CFR. Avoids annoying desync,
and makes handling much cleaner.
- Added new hidden option. IMPORT_VFR_FILM
(see HIDDENOPTS.TXT) allows you to choose
between importing VFR sources to FILM or
VIDEO (23.976/29.97 fps) rates.
- Added new hidden option. IMPORT_VFR_SCAN
(see HIDDENOPTS.TXT). Sometime MediaInfo
does not catch a VFR source. This option
tells BD-RB to perform a complete scan of
all frame timecodes in a source file to
look for VFR. Especially useful when you
can't get a file's audio to sync during
import because VFR isn't detected. It can
add a couple minutes to import time.
- Corrected an issue in which importing to
an existing import folder could result in
previous PSEUDO settings remaining even if
they no longer apply.
- Fixed an issue that remained in v0.50.21
in which a 3D source feature that is
flagged for the base view to be the right
picture was not carrying over when
outputting to a non-ALTERNATE movie-only
structure. The result would be an apparent
swapped left/right picture.
- Updated the included version of mkvextract
and mkvmerge to v9.7.1.
- Other minor corrections and cosmetic fixes.

[colinhunt]

I have updated the first post of this thread with a link to the latest version of BD-RB (v0.50.22).
jdobbs is on fire! Happy dance! Thank you once again!

[Sharc]

@jdobbs
BD-RB 0.50.22. Trying to import any of the newly added 3 lossless formats (thanks!) throws the error:
[20:17:25] Importing: HFYU
- [20:17:27] Importing video file: (1 of 1)
- Preparing AVI for processing...
- Collecting audio/video streams from source...
- Converting VFR source to CFR format...
[20:17:29]ERROR: Failed VFR conversion. Aborted
The input is CFR 25fps (according to the capture settings and in line with what MediaInfo reports) so I wonder why DB-RB wants to convert VFR to CFR.
I assume you still have my 3 testclips. Did you try with these? Do I have to force a full timecode scan?

[jdobbs]

@jdobbs
BD-RB 0.50.22. Trying to import any of the newly added 3 lossless formats (thanks!) throws the error:
[20:17:25] Importing: HFYU
- [20:17:27] Importing video file: (1 of 1)
- Preparing AVI for processing...
- Collecting audio/video streams from source...
- Converting VFR source to CFR format...
[20:17:29]ERROR: Failed VFR conversion. Aborted
The input is CFR 25fps (according to the capture settings and in line with what MediaInfo reports) so I wonder why DB-RB wants to convert VFR to CFR.
I assume you still have my 3 testclips. Did you try with these? Do I have to force a full timecode scan?Wierd. Run MediaInfo and see if it says the source is Variable Frame Rate. I'll import the examples you gave me and see what happens.


[Edit] DAMN!!! I had added a hidden option called IMPORT_VFR_FORCE for testing -- and I mistakenly defaulted it to ON. Damn. Damn. Damn. I'll fix it and post a new release in a little while. In the meantime you can set IMPORT_VFR_FORCE=0 in your INI file.

[Sharc]

[Edit] DAMN!!! I had added a hidden option called IMPORT_VFR_FORCE for testing -- and I mistakenly defaulted it to ON. Damn. Damn. Damn. I'll fix it and post a new release in a little while. In the meantime you can set IMPORT_VFR_FORCE=0 in your INI file.
No worry, no rush! Glad you found it :)

[jdobbs]

I have updated the first post of this thread with a link to the latest release of BD-RB (v0.50.23). Changes for this release:January 27th, 2016 - v0.50.23
- Added three more supported CODECs to the
import capability (HFYU, LAGS, and ULY2).
Automatic conversion to AVC will occur
during import.
- Made changes to the way VFR is handled
on import. Now it is converted, during
import, to CFR. Avoids annoying desync,
and makes handling much cleaner.
- Added new hidden option. IMPORT_VFR_FILM
(see HIDDENOPTS.TXT) allows you to choose
between importing VFR sources to FILM or
VIDEO (23.976/29.97 fps) rates.
- Added new hidden option. IMPORT_VFR_SCAN
(see HIDDENOPTS.TXT). Sometime MediaInfo
does not catch a VFR source. This option
tells BD-RB to perform a complete scan of
all frame timecodes in a source file to
look for VFR. Especially useful when you
can't get a file's audio to sync during
import because VFR isn't detected. It can
add a couple minutes to import time.
- Corrected an issue in which importing to
an existing import folder could result in
previous PSEUDO settings remaining even if
they no longer apply.
- Fixed an issue that remained in v0.50.21
in which a 3D source feature that is
flagged for the base view to be the right
picture was not carrying over when
outputting to a non-ALTERNATE movie-only
structure. The result would be an apparent
swapped left/right picture.
- Corrected an error introduced in v0.50.22
that forced VFR to CFR conversion during
import.
- Updated the included version of mkvextract
and mkvmerge to v9.7.1.
- Other minor corrections and cosmetic fixes. If you attempt to download v0.50.22 after this post -- it will also have this update included.

[jdobbs]

No worry, no rush! Glad you found it :)I had to fix it fast. Otherwise every IMPORT would result in reencoding to a huge pseudo-BD folder.

[colinhunt]

Hobbit 3D disc 2 movie-only to .ISO backup job finished, and happy to report L/R views display correctly! Thank you jdobbs; donation made.

[Sharc]

I had to fix it fast. Otherwise every IMPORT would result in reencoding to a huge pseudo-BD folder.
Still no luck. This time I am getting for all 3 codecs the error
[00:04:04] Importing: ULY2
- [00:04:06] Importing video file: (1 of 1)
- Preparing AVI for processing...
- Scanning for Variable Frame Rate...
- Collecting audio/video streams from source...
- Converting codec to compatible format...
[00:04:09]ERROR: Failed codec conversion. Aborted.

Edit:
Sorry, the problem was here: A typo in the .INI. :o
Never mind.

[Sharc]

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources? :confused:

[jdobbs]

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources? :confused:I simply use DirectshowSource() in an AVS and pass the video to X264. I would have thought that the frame format would be recognized correctly. I should have known better than to assume anything. I'll add some code to check for interlacing (bff/tff) and pass the parameter to X264..

[jdobbs]

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources? :confused:Interesting. During import all non-MKV files are remuxed into an MKV for consistency (MediaInfo reports different information, even for the same CODECs, depending upon the container). If I run MediaInfo against the AVI, it tells me the scan type is interlaced -- but if I run it against the MKV it doesn't. I guess I'm going to have to manually set the field order in MKVMERGE. That's kinda' disappointing -- you'd think something as obvious as progressive/interlaced formatting would be detected automatically.

[Edit] It gets even worse. The version of MediaInfo included with BD-RB doesn't even report the scan type as interlaced on the HFYU.avi file you sent me. And I've avoided updating it because the newer one seems to be worse at recognizing variable frame rates. And, even if I used the new one -- it doesn't tell you the field order. A wrong field order would look much worse than combining the fields and playing it as progressive.

[Sharc]

Interesting. During import all non-MKV files are remuxed into an MKV for consistency (MediaInfo reports different information, even for the same CODECs, depending upon the container). If I run MediaInfo against the AVI, it tells me the scan type is interlaced -- but if I run it against the MKV it doesn't. I guess I'm going to have to manually set the field order in MKVMERGE. That's kinda' disappointing -- you'd think something as obvious as progressive/interlaced formatting would be detected automatically.

[Edit] It gets even worse. The version of MediaInfo included with BD-RB doesn't even report the scan type as interlaced on the HFYU.avi file you sent me. And I've avoided updating it because the newer one seems to be worse at recognizing variable frame rates. And, even if I used the new one -- it doesn't tell you the field order. A wrong field order would look much worse than combining the fields and playing it as progressive.
Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario :)

[jdobbs]

Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario :)There's always a way. I'll probably have to analyze the stream myself. Look for something in the next release.

[Sharc]

There's always a way. I'll probably have to analyze the stream myself. Look for something in the next release.
Btw., capturing the tapes with x264 in lossless mode with field order specification seems to keep the interlace and field order information correctly and consistently during import. So I could capture the tapes again, but unfortunately the tapes have aged (like me) and deteriorated (like me) since the original capture in HFYU format about 8 years ago.

Now I am curious and patiently waiting for the next release of BD-RB :cool:

[MrVideo]

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.

[Lathe]

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.

Hmmmm... Can anyone say, 'BETA'...! :D

[Lathe]

...but unfortunately the tapes have aged (like me) and deteriorated (like me)...


Geez JD, do you think you could throw a little something into the next build to help ol' Sharc...?

He's decomposing before our eyes, poor fellow... http://lathe-of-heaven.com/no.gif

[MrVideo]

Hmmmm... Can anyone say, 'BETA'...! :D
Beta, VHS, whatever. It should not be giving you issues.

[Sharc]

Geez JD, do you think you could throw a little something into the next build to help ol' Sharc...?

He's decomposing before our eyes, poor fellow... http://lathe-of-heaven.com/no.gif
Nothing to really worry about, Lathe. It's in no respect as dramatic as what we see from your selfie here (http://forum.doom9.org/showpost.php?p=1791038&postcount=25431) :eek:

[Sharc]

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.
The tapes are actually much older, about 25....30 years old, but I captured (digitized) these lossless only about 8 years ago. For few of the tapes I noticed visible deterioration recently.
I posted a sample here (http://forum.doom9.org/showthread.php?p=1794052#post1794052)of a VHS tape which was still reasonably clean some years ago.

[jdobbs]

Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario :)Here's how I'm doing it. If the source is 25fps or 29.97fps, and mediainfo doesn't specifically find it to be progressive -- I will assume it is interlaced. In my testing it seems to detect and specify "Progressive" 100% correctly. Since TFF is much more common than BFF (except maybe in DV) I will make that the default. But I'll add a hidden option that can override that. It's pretty obvious when the field order is backwards -- so that will be easy to detect and correct manually.

[jdobbs]

The tapes are actually much older, about 25....30 years old, but I captured (digitized) these lossless only about 8 years ago. For few of the tapes I noticed visible deterioration recently.
I posted a sample here (http://forum.doom9.org/showthread.php?p=1794052#post1794052)of a VHS tape which was still reasonably clean some years ago.I think all my very old tapes show degradation. But since it happens gradually, you don't really notice it and you just assume it always looked that way. But when I look at an old digital capture from the same tape I can easily see it.

[Sharc]

Here's how I'm doing it. If the source is 25fps or 29.97fps, and mediainfo doesn't specifically find it to be progressive -- I will assume it is interlaced. In my testing it seems to detect and specify "Progressive" 100% correctly. Since TFF is much more common than BFF (except maybe in DV) I will make that the default. But I'll add a hidden option that can override that. It's pretty obvious when the field order is backwards -- so that will be easy to detect and correct manually.
I think this is a good strategy.

[datman]

I'm guessing this is a bug but its such an obscure use for BDRB it might be unfixable.

I posted awhile back how I was capturing video either from the DVR or the computer. The OEM software quality was lost if I processed and burned down to a BD-5 disc. I figured out that I could process it to a BD-25 size within the software then use BDRB to encode down to a BD-5 disc. Worked well but a lot of processing time from both programs.

So I tried to side step it by importing the capture TS file and it appeared to work. When I tried this prior I got nothing but coasters and it appeared that the AAC audio from the capture, which was unchanged would cause the discs not to play.

This time I unchecked both the "do not convert DTS to AC3 and do not encode AC3" This time the audio was converted to multi-ch AC3 and it plays in my BD player. The two different captures I did both sound like it's playing at 5X speed.

I tried tsMuxerGUI and it seems the AAC audio is my biggest issue. If I process it in Power Director I can convert it to DD.

[Blurayhd]

Hi guys, hi jdobbs, I have a question, lets say I want to pass to bd25 in Only movie mode but I wish to keep the Splash menu (that is calling?), You know, when you play the movie and you want to change some language or subtitles there´s some way to push the control so the Spalsh java menu appears? I know you can set all this with changing subtitles and audios but I so wish to know
Thank you for your time!!

[MrVideo]

The tapes are actually much older, about 25....30 years old
I've got a bunch of 1/4" reel-to-reel tapes that are 40-46 years old. Not one of which had issues when I played them back for capturing. And yes, the Sony reel-to-reel deck is also functioning after all these years. Storage conditions were not ideal either.

[Lathe]

Nothing to really worry about, Lathe. It's in no respect as dramatic as what we see from your selfie here (http://forum.doom9.org/showpost.php?p=1791038&postcount=25431) :eek:

I swear... you try to show a little concern and this is what you get... :rolleyes:

[Lathe]

I've got a bunch of 1/4" reel-to-reel tapes that are 40-46 years old. Not one of which had issues when I played them back for capturing. And yes, the Sony reel-to-reel deck is also functioning after all these years. Storage conditions were not ideal either.

Reel-to-Reel...???! Holy Smokes! What's next, you gonna break out your Edison wire spools...?

How frigg'n OLD are you, for God's sake!? :eek:

(this almost reminds me of the old Monty Python sketch, 'Well, when I was young, we had to etch our own recordings in granite...')