Basic Questions

[Woodstock]

If the glitch moves around on playback, it's more likely a problem with the player than the file. Or, more precisely, the player cannot deal with the bandwidth different sections require.

[Kettykrueger]

Thanks Woodstock.

I tried the file on Plex and VLC, the glitch was present at the same time in both.

[Kettykrueger]

Just to add, this is not the first disc to happen to.

Playing files on different platforms, glitching in the same place. Re-ripping, still have glitches but in different places.

If it’s not MakeMKV could it be the hard drive or the optical drive?

Really at a loss!

[Woodstock]

On BD sources, MakeMKV does a checksum of the files and tests it against the checksums on the disk; it is unusual for something to pass that process and have a glitch like you describe. Not impossible, just very, very unlikely.

If you play it in both, does the glitch occur in the same frame? Near a scene change? When there is suddenly a lot of action on the screen?

[Kettykrueger]

It’s the exactly same frame.

Only occurred once with this title but I’ve experience similar things with other titles.

[Kettykrueger]

Any other ideas, dude?

Could it be optical drive?

On BD sources, MakeMKV does a checksum of the files and tests it against the checksums on the disk; it is unusual for something to pass that process and have a glitch like you describe. Not impossible, just very, very unlikely.

If you play it in both, does the glitch occur in the same frame? Near a scene change? When there is suddenly a lot of action on the screen?

[Woodstock]

There are a lot of things it COULD be.

On a BD source where the play list consists of multiple M2TS files stitched together, scene transitions can be "rough", because the video transitions more abruptly than normal. Some segments might not even be the same resolution as the next, and the player is expected to make the transition.

Another possibility is that the glitch is intentional - but that is rare, unless you've picked the wrong play list on an obfuscated Lionsgate disk.

Do you have handbrake? One thing to try is to encode the video with it, and see if the glitch disappears. If it is a case of the transition being badly handled, SOMETIMES handbrake will smooth it out by inserting a proper key frame where the glitch happens. You don't have to encode the whole thing to test it; if you know where the glitch is, you can encode just that section and see if it fixes things.

[Kettykrueger]

Thanks, I’ll certainly try that.

I find it odd that it’s on most of my rips though. And this is the second time I’ve had to rip them. The first time, they all worked perfectly. This time round, many/most have corruption in them.

There are a lot of things it COULD be.

On a BD source where the play list consists of multiple M2TS files stitched together, scene transitions can be "rough", because the video transitions more abruptly than normal. Some segments might not even be the same resolution as the next, and the player is expected to make the transition.

Another possibility is that the glitch is intentional - but that is rare, unless you've picked the wrong play list on an obfuscated Lionsgate disk.

Do you have handbrake? One thing to try is to encode the video with it, and see if the glitch disappears. If it is a case of the transition being badly handled, SOMETIMES handbrake will smooth it out by inserting a proper key frame where the glitch happens. You don't have to encode the whole thing to test it; if you know where the glitch is, you can encode just that section and see if it fixes things.

[Kettykrueger]

So that didn't work! I converted it with Handbrake and the glitch is still there.

Any other ideas?

Thanks

There are a lot of things it COULD be.

On a BD source where the play list consists of multiple M2TS files stitched together, scene transitions can be "rough", because the video transitions more abruptly than normal. Some segments might not even be the same resolution as the next, and the player is expected to make the transition.

Another possibility is that the glitch is intentional - but that is rare, unless you've picked the wrong play list on an obfuscated Lionsgate disk.

Do you have handbrake? One thing to try is to encode the video with it, and see if the glitch disappears. If it is a case of the transition being badly handled, SOMETIMES handbrake will smooth it out by inserting a proper key frame where the glitch happens. You don't have to encode the whole thing to test it; if you know where the glitch is, you can encode just that section and see if it fixes things.

[Woodstock]

What titles are you having the issue with? Maybe some others here have had the same issue and not said anything at this point...

[Kettykrueger]

There’s too many to list!

I don’t think it’s the title/disc as I’ve ripped them before and had no problems with the outputs.

Could ripping to an external drive be a problem? Maybe it’s sleeping during ripping?

What titles are you having the issue with? Maybe some others here have had the same issue and not said anything at this point...

[Woodstock]

External drives can have issues with ripping long titles, if they're USB-powered. The drive electronics "hiccup" if the drive is spun too fast for the available power, can the operating system gets upset about it.

However, when that happens, the location varies, and MakeMKV will error out, and the file will be deleted. The same occurs if the drive (internal or external) decides to spend too much time reading a sector that has problems; The OS times out, the file is declared bad, and MakeMKV deletes it.

For MakeMKV to have saved the file, it passed a checksum test at the end, which is why this seems so weird.

[Kettykrueger]

Did the log file I posted earlier not give any clues?

Thanks again for taking the time to reply

External drives can have issues with ripping long titles, if they're USB-powered. The drive electronics "hiccup" if the drive is spun too fast for the available power, can the operating system gets upset about it.

However, when that happens, the location varies, and MakeMKV will error out, and the file will be deleted. The same occurs if the drive (internal or external) decides to spend too much time reading a sector that has problems; The OS times out, the file is declared bad, and MakeMKV deletes it.

For MakeMKV to have saved the file, it passed a checksum test at the end, which is why this seems so weird.

[Woodstock]

The debug codes in the log are something Mike would have to look at. He holds the magic decoder ring that says what they mean.

[Kettykrueger]

How do we summon him?

The debug codes in the log are something Mike would have to look at. He holds the magic decoder ring that says what they mean.