MakeMKV v.1.4.6 hidden significant problem

[setarip_old]

@Mike Chen

I used MakeMKV v.1.4.6 to rip the Extended Version movie-only of the recently released "Gladiator" BluRay.

The size of the resultant MKV was 30,855,012KB.

1) I then used tsMuxeR v.1.10.6 to re-convert the movie-only into a BluRay "package" (Something I have now done without incident with more than 100 original BluRay discs).

To my surprise, while the original disc and the MKV both played in perfect synch from the start to the finish of the movie, the re-converted BluRay "package" started out in synch and then ever so slowly (starting at about 1:09:00) drifts out of synch, until it's about 2 seconds out of synch by the end of the movie!

2) I resurrected MakeMKV v.1.4.5 and repeated the procedures exactly, using this slightly older version.

The size of the resultant MKV was 30,855,375KB - 363Kb more than with v.1.4.6!

After re-converting this MKV to a movie-only BluRay "package", I played it - and it stayed in perfect synchronization from start to finish!

Hopefully Mike Chen etal will be able to resolve this aberrant behavior...

[Mike Chen]

There was a major rewrite of MKV mux code in 1.4.6 so produced MKV files are more compatible with various players, that led to size difference. As for sync, I would need more data. Please PM me.

[setarip_old]

@Mike Chen

As for sync, I would need more data.

There is no additional data. If you obtain the U.S. version of the "Gladiator" BluRay and perform the identical steps that I've posted, you'll have your source for analysis of this possibly title-specific asynch problem...

[Mike Chen]

Originally Posted by setarip_old

@Mike Chen

There is no additional data. If you obtain the U.S. version of the "Gladiator" BluRay and perform the identical steps that I've posted, you'll have your source for analysis of this possibly title-specific asynch problem...

I was going to ask you to send me output of "mkvinfo -v -c" for each mkv file, since it should show the problem without the need to obtain the disc. These files would be rather big but they compress fine.

[Mike Chen]

Originally Posted by setarip_old

@Mike Chen

There is no additional data. If you obtain the U.S. version of the "Gladiator" BluRay and perform the identical steps that I've posted, you'll have your source for analysis of this possibly title-specific asynch problem...

If you still have the disc I would appreciate if you can test it with 1.4.8 .

[setarip_old]

@Mike Chen

If you still have the disc I would appreciate if you can test it with 1.4.8 .

1) Of course I still have my purchased disc.

2) I just repeated my earlier stated procedures, this time using v.1.4.8 as you requested. I'm pleased to report that the previous problem appears to have been overcome with this version.

IMPORTANT - Your website now shows a 672 byte file "dscombo.svq", pertinent to BD+ disc-ripping. Information is not very clear:

1) Does this 672 byte file PRESENTLY include any generic or disc-specific information/keys?

2) If so, how is it made available/accessed/viewable? If not, what is its purpose?


Please advise...

[Mike Chen]

Originally Posted by setarip_old

1) Does this 672 byte file PRESENTLY include any generic or disc-specific information/keys?

Yes, it includes disc-specific SVQs for 11 (i believe) titles created from dumps that were sent to us.

Originally Posted by setarip_old

2) If so, how is it made available/accessed/viewable? If not, what is its purpose?

You download it into "SVQ directory" (set in preferences) and these titles start work.

[derbeDeus]

Originally Posted by Mike Chen

Yes, it includes disc-specific SVQs for 11 (i believe) titles created from dumps that were sent to us.

12. if there is only 0x34 worth of data per disc and discid would be 0x14 of that... it is a very cool system. is bd+ hanging only in 0x20 bytes?
btw what is svq anyway?

[Mike Chen]

Originally Posted by derbeDeus

12. if there is only 0x34 worth of data per disc and discid would be 0x14 of that... it is a very cool system. is bd+ hanging only in 0x20 bytes?

we've updated the svq today, now its 14. discid in svq is 16 bytes, so yes, all keys and settings to execute latest BD+ protections fit in 0x38 bytes. generic SVQ that we use to create these has comparable size.

Originally Posted by derbeDeus

btw what is svq anyway?

svm quirk.

[setarip_old]

@Mike Chen

I am feeling more unabsorbing than usual ;>}

How is the user to know WHICH BD+ BluRay discs are already included in the (growing) SVQ file?

I would like to know this information BEFORE I purchase any BD+ releases (presently only Fox releases, with the possible near term addition of Paramount releases).

How can this be done?

[setarip_old]

@Mike Chen

The way you/your company has chosen to deal with us, the users/beta testers regarding the BD+ function seems grossly unfair:

On one hand, although you appear to have it, you are NOT providing the generic key for earlier releases to us.

On the other hand, rather than providing us with the tool that would allow us to create our own "SVQ" file information from "dump files" created from OUR purchased BluRay discs, you are compelling us to to provide you/your company with our information.

Please justify your thinking regarding this.

As a sign of good faith, I'd propose that you/your company make the generic key for prior releases available to us, the users/beta testers.

[Mike Chen]

Originally Posted by setarip_old

@Mike Chen

The way you/your company has chosen to deal with us, the users/beta testers regarding the BD+ function seems grossly unfair:

Please take my word that the reasons to keep things as they are purely technical. Do you think that our team doesn't have a pride and we don't want to see quotes like "makemkv for linux and mac can process bd+ discs that anydvd on windows can't"? If we could release generic svq today, we'd did it instantly.

Originally Posted by setarip_old

On one hand, although you appear to have it, you are NOT providing the generic key for earlier releases to us.

We do not have a generic key just for "earlier releases", we just have a generic key. That works today, that will work tomorrow, that will work forever until it is released. All keys come from players - the generic SVQ will pinpoint the player so its keys will be revoked shortly afterwards. Generic SVQs are very much like processing keys - they enable all discs made before they become public, and then they die.

Originally Posted by setarip_old

On the other hand, rather than providing us with the tool that would allow us to create our own "SVQ" file information from "dump files" created from OUR purchased BluRay discs, you are compelling us to to provide you/your company with our information.
Please justify your thinking regarding this.

I do not like it either, but I do not see any other solution for the moment. We set up a dedicated email account for dump drops and we delete all incoming messages after copying the dump file. The dump file itself is a tar.gz archive (so you can examine its contents) that contains olny some control files from disc, it contains no user/personal information and it contains no A/V data. The svq@makemkv.com email is just a convenient way to communicate. We need a dump file and not personal information, so feel free to pass this dump by any other way - put to rapidshare and send us a link, or something similar.

Originally Posted by setarip_old

As a sign of good faith, I'd propose that you/your company make the generic key for prior releases available to us, the users/beta testers.

There are some technical reasons that I can't share and you won't understand (without deep knowledge of BD+ design) that stand behind our behavior. If we make generic SVQ available right now, it will be revoked shortly and our ability to obtain keys in future might be compromised. We do have a plan how to release a generic SVQ without compromising "future BD+ hackability" but it will take some time.

On the other hand disc-specific SVQs are like volume keys - they unlock a single disc but they contain no information about how they were created. So AACS/BD+ folks know that we have a key and know how to use it but they do not know which specific key out of 65529 non-revoked keys do we have. That allows us to enable BD+ for everyone and still work on improving our BD+ implementation. Releasing generic SVQ now will only burn a resource that is very hard to come by.

[Mike Chen]

Originally Posted by setarip_old

How is the user to know WHICH BD+ BluRay discs are already included in the (growing) SVQ file?

Even we do not know which particular discs are there - svq is built from dumps that are sent to us and they contain just a disc name. I know for example that current SVQ includes 2 quantums of solace and one wolverine but I have no idea if it is US or european or australian disc. The only real way to test is to try the disc. If it does not work I encourage you to send us the "dump" - its size is about 500K and we'll include SVQ for this disc as soon as we get it.

On the other hand the current absence of a generic SVQ is a temporary thing. Generic SVQ will be released sooner or later and this nuisance will go away.

[setarip_old]

svq is built from dumps that are sent to us and they contain just a disc name. I know for example that current SVQ includes 2 quantums of solace and one wolverine but I have no idea if it is US or european or australian disc.

Then I would request that you make available a constantly updated companion "SVQ Titles only" (no regions, since you don't know) list that can be downloaded together with the SVQ list.

Your thoughts, please?

[Mike Chen]

Originally Posted by setarip_old

Then I would request that you make available a constantly updated companion "SVQ Titles only" (no regions, since you don't know) list that can be downloaded together with the SVQ list.

Your thoughts, please?

I do not see how this list would be useful in any way. But I respect your request so the sticky BD+ post on our forum has an up-to-date list of titles from now on.

[setarip_old]

@Mike Chen

Thank you ;>}