Is this a drive failing?

[mwebb]

Hi there team,

I'm currently using a Pioneer BDR-S12U as may main UHD ripping drive, and things seem to have be working smoothly for a number of years. Windows 10, drive firmware 1.01 running in LibreDrive mode. Updated to WIndows 11 in October.

I've recently ripped Arrow's UHD of the thetrical The Good, The Bad and The Ugly. Rip copleted fine however on replay there were a couple of sections that displayed a number of video breakups in VLC. Ripped again, and again completed without error; output file is the same size to the byte. Replay in VLC still shows breakups, however now in different locations.

I didn't think a rip could complete cleanly and then result in a corrupted file. Could this realistically be anything other than a failing Bluray drive?

Thanks for your input.

[MartyMcNuts]

Hi there team,

I'm currently using a Pioneer BDR-S12U as may main UHD ripping drive, and things seem to have be working smoothly for a number of years. Windows 10, drive firmware 1.01 running in LibreDrive mode. Updated to WIndows 11 in October.

I've recently ripped Arrow's UHD of the thetrical The Good, The Bad and The Ugly. Rip copleted fine however on replay there were a couple of sections that displayed a number of video breakups in VLC. Ripped again, and again completed without error; output file is the same size to the byte. Replay in VLC still shows breakups, however now in different locations.

I didn't think a rip could complete cleanly and then result in a corrupted file. Could this realistically be anything other than a failing Bluray drive?

Thanks for your input.

The disc could have a scratch or something but more likely to be a codec or hardware issue on playback. What are your PC specs?

[mwebb]

PC is an old i7 NUC. I normally use an OSMC Vero V for replay and I originally noticed the problem as this was suffering from replay stuttering in the problem sections. I then noticed that VLC on my PC shows picture breakup where the Vero stutters. The PC may be underpowered, but the Vero V certainly shouldn't be. ANywho, I feel really confident that the problem is in the output file and not just the replay device.

[mwebb]

After some testing I note that with this disc as source, every time I rip the movie the resulting MKV is of the same length but has a different MD5 hash code.

...is that normal because of a different date and time stamp encoded in the Matroska metadata?

[keydb_helper]

I didn't think a rip could complete cleanly and then result in a corrupted file.

MakeMKV validates the data as it is read via the AACS content hash tables. Any corrupt data should be flagged during reading.

Try to open the ripped MKV file in a video editor such as Avidemux to see whether the corruption you noticed during playback is reproducible when stepping through problematic timestamps frame by frame.

After some testing I note that with this disc as source, every time I rip the movie the resulting MKV is of the same length but has a different MD5 hash code.

...is that normal because of a different date and time stamp encoded in the Matroska metadata?

Yes, that is to be expected.

[mwebb]

I'll give the Avidemux check a go. I've just started running recent rips through ffmpeg -v error and everything I've checked from recent ripping has errors. I'm just going back to something the pre-dates my Windows 11 update in October.

I've also re-commissioned my old BU40N drive, and tried ripping this disc to different destination drives. All combinations currently generate some degree of errors according to ffmpeg.

[mwebb]

Avidemux appears to confirm corruptions in the output video stream.

I've run a number of ffmpeg -v error -i on various ripped MKV and so far they have all shown at least one error, but nowhere near as bad as this current example.

[kaysee]

If you used MakeMKV to read the UHD disc, then a non-error completion (meaning file hashes of read data were checked) indicates that reading was successful.

However, if you have a flakey setup for writing the copied data, then what was actually saved could have errors, even if the data that the system was attempting to write was itself correct. That could affect not just optical disc copying, but any data written to the drive, and could also result in the filesystem getting corrupted.

Typical causes of this are bad data or power cables, or an underpowered USB connection (like a computer's or hub's USB port with limited USB power output). So a connected external SSD or portable hard drive may have just enough power to be seen by the host computer and occasionally write some data successfully, but will write bad data from time to time, or go offline suddenly without completing a deferred write, etc. For example, I know that with a powered USB hub that I use, when I connect an external SSD or portable hard drive to it with the hub's power supply active, things work well. If I do not connect the hub's power supply, the USB bus supplies enough power to make the storage device visible an able to write some data, sometimes incorrectly, and occasionally go offline suddenly -- meaning enough power to cause trouble.

[Coopervid]

I second this and highly doubt that you are on the right track concerning the drive. It is something that happens after ripping. Maybe a bad Wifi transfer or too low speed if you use Wifi for playing back.

[mwebb]

I'd be pleased for it not to be the optical drive. I have the optical drive directly connected to a USB port on the NUC and am writing to the internal SATA HDD. Rip of the main movie completes without error. ffmpeg with -v error -i then tells me there are errors in the file. Chkdsk comes back clean. Nothing else seems to be playing up as far as I can see. I'm at a loss really.

[kaysee]

If you have copied the disc more than once and kept the resulting files, then you can compare the files or their hashes. If these are the same, that the data is what is on the optical disc. I use hashdeep.

[kaysee]

I should add that the "Backup" operation of MakeMKV should yield identical results each time, which is a copy of the whole disc. Things could differ from one copy to another depending on selections and other things in the MKV copy mode.

[MartyMcNuts]

I'd be pleased for it not to be the optical drive. I have the optical drive directly connected to a USB port on the NUC and am writing to the internal SATA HDD. Rip of the main movie completes without error. ffmpeg with -v error -i then tells me there are errors in the file. Chkdsk comes back clean. Nothing else seems to be playing up as far as I can see. I'm at a loss really.

If MakeMKV tells you there is no error, then why are you checking again with ffmpeg? I would trust MakeMKV over ffmpeg's error check.

[Coopervid]

I'd be pleased for it not to be the optical drive. I have the optical drive directly connected to a USB port on the NUC and am writing to the internal SATA HDD. Rip of the main movie completes without error. ffmpeg with -v error -i then tells me there are errors in the file. Chkdsk comes back clean. Nothing else seems to be playing up as far as I can see. I'm at a loss really.

I somehow think that your distortions are created at points where the bitrate of the movie exceeds the transfer speed in your playback chain. To check for it is quite easy. Download FFBitrateViewer from here:

https://github.com/fifonik/FFBitrateViewer

You also need to download FFMPEG from here:

https://www.videohelp.com/software/ffmpeg

and copy ffprobe.exe in the FFBitrateViewer directory.

Then load the .m2ts and let it analyze. Switch the output view to seconds and compare the timestamp with the highest bitrate(s) with the timestamp where your distortions appear.

[kaysee]

Also, if you play video using one of the Media Player Classic editions, it will indicate a count of dropped frames.