Video cuts short audio continues, no error?

[setarip_old]

Using 44.09 on "The Cowboys" (John Wayne). Original Main Movie has a total length of 2:14:28.

BD-RB compressed version, video freezes at 1:41:22, audio continues to correct end at 2:14:28.

----------------------
[05/23/13] BD Rebuilder v0.44.09 (beta)
[15:49:46] Source: COWBOYS
- Input BD size: 20.81 GB
- Approximate total content: [02:55:50.564]
- Target BD size: 7.84 GB
- Windows Version: 6.0 [6002]
- Quality: Better (Faster), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[15:49:46] PHASE ONE, Encoding
- [15:49:46] Processing: VID_00000 (1 of 10)
- [15:49:46] Extracting A/V streams [VID_00000]
- [15:55:23] Reencoding video [VID_00000]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 193,428 frames
- Bitrate: 6,036 Kbs
- [15:55:23] Reencoding: VID_00000, Pass 1 of 1
- [19:41:27] Video Encode complete
- [19:41:27] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4355 (eng): Keeping original audio
- [19:42:02] Multiplexing M2TS
- [19:46:03] Processing: VID_00001 (2 of 10)
- [19:46:03] Extracting A/V streams [VID_00001]
- [19:46:07] Reencoding video [VID_00001]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 289 frames
- Bitrate: 2,609 Kbs
- [19:46:07] Reencoding: VID_00001, Pass 1 of 1
- [19:46:23] Video Encode complete
- [19:46:23] Processing audio tracks
- [19:46:23] Multiplexing M2TS
- [19:46:26] Processing: VID_00002 (3 of 10)
- [19:46:26] Extracting A/V streams [VID_00002]
- [19:46:31] Reencoding video [VID_00002]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 241 frames
- Bitrate: 2,833 Kbs
- [19:46:31] Reencoding: VID_00002, Pass 1 of 1
- [19:46:49] Video Encode complete
- [19:46:49] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:46:49] Multiplexing M2TS
- [19:46:53] Processing: VID_00010 (4 of 10)
- [19:46:53] Extracting A/V streams [VID_00010]
- [19:46:57] Reencoding video [VID_00010]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 552 frames
- Bitrate: 2,029 Kbs
- [19:46:58] Reencoding: VID_00010, Pass 1 of 1
- [19:47:20] Video Encode complete
- [19:47:20] Processing audio tracks
- [19:47:20] Multiplexing M2TS
- [19:47:24] Processing: VID_00012 (5 of 10)
- [19:47:24] Extracting A/V streams [VID_00012]
- [19:48:05] Reencoding video [VID_00012]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 51,509 frames
- Bitrate: 1,704 Kbs
- [19:48:05] Reencoding: VID_00012, Pass 1 of 1
- [19:58:06] Video Encode complete
- [19:58:06] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:58:07] Multiplexing M2TS
- [19:58:17] Processing: VID_00013 (6 of 10)
- [19:58:17] Extracting A/V streams [VID_00013]
- [19:58:31] Reencoding video [VID_00013]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 15,879 frames
- Bitrate: 1,721 Kbs
- [19:58:32] Reencoding: VID_00013, Pass 1 of 1
- [20:01:05] Video Encode complete
- [20:01:05] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [20:01:05] Multiplexing M2TS
- [20:01:11] Processing: VID_00014 (7 of 10)
- [20:01:11] Extracting A/V streams [VID_00014]
- [20:01:18] Reencoding video [VID_00014]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 5,584 frames
- Bitrate: 1,699 Kbs
- [20:01:19] Reencoding: VID_00014, Pass 1 of 1
- [20:02:13] Video Encode complete
- [20:02:13] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [20:02:13] Multiplexing M2TS
- [20:02:17] Processing: VID_00017 (8 of 10)
- [20:02:17] Extracting A/V streams [VID_00017]
- [20:02:22] Reencoding video [VID_00017]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 12 frames
- [20:02:22] Reencoding: VID_00017, Pass 1 of 1
- [20:02:24] Video Encode complete
- [20:02:24] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4354 (eng): Keeping original audio
- Track 4355 (eng): Keeping original audio
- [20:02:24] Multiplexing M2TS
- [20:02:28] Processing: VID_00018 (9 of 10)
- [20:02:28] Extracting A/V streams [VID_00018]
- [20:02:32] Reencoding video [VID_00018]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 15 frames
- [20:02:32] Reencoding: VID_00018, Pass 1 of 1
- [20:02:33] Video Encode complete
- [20:02:33] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [20:02:33] Multiplexing M2TS
- [20:02:36] Processing: VID_00026 (10 of 10)
- [20:02:36] Extracting A/V streams [VID_00026]
- [20:02:40] Reencoding video [VID_00026]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 30 frames
- [20:02:40] Reencoding: VID_00026, Pass 1 of 1
- [20:02:41] Video Encode complete
- [20:02:41] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [20:02:41] Multiplexing M2TS
[20:02:45]PHASE ONE complete
[20:02:45]PHASE TWO - Rebuild Started
- [20:02:45] Rebuilding BD file Structure
[20:02:46] - Encode and Rebuild complete
[20:02:46] JOB: COWBOYS finished.
----------------------

Log indicates good completion. What could cause this?

[Ghitulescu]

have you checked whether the video_01 (probably 00000.M2TS) was error-free before encoding?

[RobertM]

I've had this happen a number of times, and it was always a bad rip. Take a look at your original rip, at the very spot where the freeze happens, and see if you can detect any video glitches.

[jdobbs]

Yep. I've seen it a few times too. It has always been the result of a bad rip. In most cases attempting to play that section on the original (copy) shows a glitch of some sort at that point.

[RobertM]

Why it is that BD players, both standalone and s/w, seem to be able to skip over many of those glitches and keep going, with relatively little pain? There seems to be some kind of error skipping function built-in, which is not quite like the error correction functions used in the copying/re-encoding functions. I've had scratched discs (CD, DVD, BD) that will stop a file copy in its tracks, but can play back fully with only a little "burp".

[Ghitulescu]

That's simple - BD-, DVD- and CD-players are audio-visual gear, the computer drives are computer (ie data-oriented).
A/V-gear MUST provide the viewer a real-time image or sound, otherwise their use looses its sense.
A computer gear MUST provide the integral data, otherwise they looses their functionality.

Any player has anti-skip measures built-in. Otherwise the tiniest scratch would cause a glitch.

[setarip_old]

All is well. Remarkable! It took two MORE scrupulous cleanings (still no errors generated) to get a flawless rip.

Thanks to all ;>}

[RobertM]

It took two MORE scrupulous cleanings (still no errors generated) to get a flawless rip.

The errors that fail silently are really tricky. In contrast, I've had cases where the disc surface looked pristine, no scratches, smudges, etc., but, regardless of what I tried, there was always a read error. After trying a few techniques I just have to abandon the effort. Some pressed discs are just worse than others.

Good that your problem is resolved.

[RobertM]

Any player has anti-skip measures built-in. Otherwise the tiniest scratch would cause a glitch.

Right. That's my point. If it's possible for standalone players then why not in my PC? After all, these days isn't an optical drive basically an optical drive?

My thinking is that pure playback devices, like a standalone BD player, can be more forgiving because the data is temporary and feeds into a data stream that doesn't have to be bit perfect. Continuity of the data stream is more important than absolute data integrity. So they can build in some ability to ignore errors, just throw them out, knowing that the end result might have a couple of glitches but it will be better overall. This error correction seems to work pretty well, and it's not likely any kind of hardware difference, but a firmware/software difference.

On a PC the data transfer usually has to be bit perfect, or we'd have corrupt files all over the place. So we generally wouldn't want to include this type of error skipping, except when processing non-executable files, like sound, video, image, etc. For those files, having 99% of the data might be better, at least as an option, than having none.

Anyway, just typing out loud... ;)

[jdobbs]

Right. That's my point. If it's possible for standalone players then why not in my PC? After all, these days isn't an optical drive basically an optical drive?

My thinking is that pure playback devices, like a standalone BD player, can be more forgiving because the data is temporary and feeds into a data stream that doesn't have to be bit perfect. Continuity of the data stream is more important than absolute data integrity. So they can build in some ability to ignore errors, just throw them out, knowing that the end result might have a couple of glitches but it will be better overall. This error correction seems to work pretty well, and it's not likely any kind of hardware difference, but a firmware/software difference.

On a PC the data transfer usually has to be bit perfect, or we'd have corrupt files all over the place. So we generally wouldn't want to include this type of error skipping, except when processing non-executable files, like sound, video, image, etc. For those files, having 99% of the data might be better, at least as an option, than having none.

Anyway, just typing out loud... ;)Exactly. The error is there on both devices almost all the time. But when all you have to do is playback -- you can ignore the error and recover. For the most part you can't do that when you are depending on the O/S to give you a bit-for-bit copy -- and especially in encoding -- too many dependencies.

[Ghitulescu]

The errors that fail silently are really tricky. In contrast, I've had cases where the disc surface looked pristine, no scratches, smudges, etc., but, regardless of what I tried, there was always a read error. After trying a few techniques I just have to abandon the effort. Some pressed discs are just worse than others.

It shouldn't happen. However I've seen PC units advertising "smooth playback" or similar. To me this is an indication that the drive interpolates the data.