View Single Post
Old 13th January 2018, 23:24   #12  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 259
Data in your database does not have to be limited to data in keydb. You can build an entire Bluray movie database if you want, even IMDb codes can be useful.

Keydb specification can be found here. Even though VUK is sufficient to play a certain disc (ignoring bd+, bus encryption, playlist obfuscation and other DRM crap), I have explained here why it is a mistake to collect only VUK

Even if keydb does not have support for some data, it should still be collected as separate data fields in the database (e.g. BD+, MKBrev, Region) and can be written in the keydb comment field. Keydb should be regarded as just 1 kind of output format. There should be for example CSV or SQL output which is much easier to work with for data analysis.

For example, a FindVUK XML
Code:
<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
	<FileType>BlurayMetaXML</FileType>
	<DiscId Date="2011-06-06">113B873574ABF236895BE54376AA14649DA0152E</DiscId>
	<VolumeId>A56C5A7AAAA8CBDE3D83834C836D8830</VolumeId>
	<MediaKey>DF991ABB947C503E4BC18DC09F4F5579</MediaKey>
	<VolumeUniqueKey>73C153CC28B32B650F23F8A9891331B9</VolumeUniqueKey>
	<VolumeLabel>RETURN_OF_THE_JEDI</VolumeLabel>
	<BDplus Date="2011-05-04">1</BDplus>
	<BusEncryptionEnabled>0</BusEncryptionEnabled>
	<MKBrev>19</MKBrev>
	<MainPlaylist>00800.mpls</MainPlaylist>
	<UnitKeys>
		<UnitKey Nr="1">04B80421D00B2C68134BCE7807421287 </UnitKey>
		<UnitKey Nr="2">85581552DC02679109AF39A4EA5077EB </UnitKey>
		<UnitKey Nr="3">013BE88A01E408202A1994CD0252184C </UnitKey>
		<UnitKey Nr="4">C2E9C5B3D4D68C80EBD4982C2D0B0584 </UnitKey>
		<UnitKey Nr="5">BA966BE272D3AD16EAF4F2FF2A596B38 </UnitKey>
		<UnitKey Nr="6">9571943B2E4CBA7CDADF6EA2D70141A1 </UnitKey>
		<UnitKey Nr="7">6FB81616BF05A6A554CF99B396FF260D </UnitKey>
	</UnitKeys>
	<MetaTitles>
		<MetaTitle Language="eng">Return of the Jedi</MetaTitle>
		<MetaTitle Language="fra">Le retour du Jedi</MetaTitle>
	</MetaTitles>
</Bluray>
can become a keydb.cfg entry similar to this:

Code:
0x113B873574ABF236895BE54376AA14649DA0152E = RETURN_OF_THE_JEDI (Return of the Jedi) 
| D | 2011-06-06 
| V | 0x73C153CC28B32B650F23F8A9891331B9 
| U | 1-0x04B80421D00B2C68134BCE7807421287 | 2-0x85581552DC02679109AF39A4EA5077EB | 3-0x013BE88A01E408202A1994CD0252184C 
     | 4-0xC2E9C5B3D4D68C80EBD4982C2D0B0584 | 5-0xBA966BE272D3AD16EAF4F2FF2A596B38 | 6-0x9571943B2E4CBA7CDADF6EA2D70141A1 | 7-0x6FB81616BF05A6A554CF99B396FF260D 
| M | 0xDF991ABB947C503E4BC18DC09F4F5579 
| I | 0xA56C5A7AAAA8CBDE3D83834C836D8830 
; FindVUK 1.02/MKBv19/BD+/Region-B-/Playlist00800
If you only take input from "trusted" sources like FindVuk you should not be too concerned with validation of the data or calculation of MK/VID to VUK (although without encryption anyone can fake entries). I just wanted to point out that there will be submissions for the same DiscId containing different data, for a multitude of reasons. You need to take into account how to deal with such scenarios as without access to the actual disc, the data is hard or impossible to verify.

With support for regular Bluray, we are not talking about a database of 200 UHD discs, easily maintainable manually. This will be in the region of 80.000 known DiscIds just to start with (and several 100.000 UPC if you want to track those)

Also it should be possible to submit from sources other than FindVUK, e.g. a program similar to AACSUpdater (this could even be built in to FindVUK) can harvest DiscID/VUK/VID keys from VLC AACS cache directories

Last edited by candela; 14th January 2018 at 00:18.
candela is offline   Reply With Quote