How to interpret offset into timestamp?

[AlreadyFree]

I have a blu-ray iso file that I ripped a number of years ago and now I'm trying to convert it to a mkv. I don't remember getting any read errors when I originally ripped this iso but running it through makemkv I get several corrupt sector messages such as this:

Code: Select all

The source file '/BDMV/STREAM/00800.m2ts' is corrupt or invalid at offset 43644112896, attempting to work around
DEBUG: Code 184 at fRe7Tf.X>q:*CJ*_~hmr?:213134055
DEBUG: Code 184 at fRe7Tf.X>q:*CJ*_~hmr?:213134055

What does the offset number reference (43644112896)? I'm assuming a specific frame or timestamp within the video file. How do I read the offset number or convert to know what timestamp it's referencing so that I can check the mkv file at that timestamp to determine if there is really any visual or audible errors at that point or not?

[AlreadyFree]

Nobody knows what the reported offset numbers mean? What's the point of even reporting the number if there's nothing a user can do with the information? It must refer to a timeframe within the bluray .m2ts file but I'm surprised there's no explanation anywhere (or even an automatic conversion to the equavilant timeframe within the makemkv log itself).

[Woodstock]

It may be that no one that has seen your message yet knows EXACTLY what it means.

I've always assumed that it was referring to the offset within the file in question, i.e., 43,644,112,896 bytes offset from the beginning of the file. The exact placement doesn't matter so much, because it will either vary somewhat (not be the same every attempt to read) or be exactly the same each time.

Varying is often because of a "read glitch" that isn't fixed to same exact spot each time, and might be tied to how fast the drive is trying to read that particular point on the disk It will try multiple times to read it.

Exactly the same spot each time points to a bad spot on the disk, which usually means cleaning the disk is necessary.

If MakeMKV continues to read past that point, it was able to get a good copy after several attempts.

[AlreadyFree]

Well I didn't think of the offset number being the number of bytes from the beginning of the file, that sounds very possible. But i still can't think of how I could convert that to a time so that I could play the resulting file and visually check for errors. It wouldn't need to be a precise time, just a general range would work so that watching the whole file wouldn't be necessary.

With this particular instance I'm making an mkv from a previously ripped iso so there shouldn't be an actual read errors, unless there's a defect on my hard drive (horror that's not the case).

[Woodstock]

If MakeMKV doesn't STOP the read, it was able to get a complete set of data. That's one of the things that people complain about - "It was able to get 99.9% of the data, why didn't it write the file?!?"

If MakeMKV does write a file, it's because it thinks it got a complete file. The debug codes are information about what it tried, and only the author of the program can interpret them, BUT!!! a successful write is evidence that it was able to get an error-free read.

[dcoke22]

It might be the case that the OP ripped the original with something other than MakeMKV. I'm not sure other rippers are as picky about ensuring a clean rip as MakeMKV is.

Regardless if a bit flipped on the OP's hard drive or the original rip had defects, now it seems MakeMKV is detecting a structural defect in the file. If the offset is the number of bytes from the beginning of the file where the defect is detected, that translates to about 40.5GB. Assuming the file 00800.m2ts is at least that big, you could make a rough approximation of where in the file the defect occurs. If this a normal 1080p blu-ray, it is likely near the end.

[AlreadyFree]

Do none of the developers of MakeMKV post on this forum? I can't believe that there is no definitive answer for this.