OpenMG file formats

OMG File format LP2
found in Documents and Settings\All Users\Application
Data
	\Sony.....etc.

After examining a number of the data files associated
with OpenMG I noticed that many have an idential
format.

files which I know have this format include:
	
	\Program Files\Common Files\Sony Shared\OpenMG
		\procfile\??\*.opf
		\OMGKEY\omg.dat
		\EMDKEY\???\cert.dat
		\EMDKEY\???\priv.dat
	\Documents and Settings\All Users
           \Application Data\Sony Corporation
           \OpenMG Jukebox\Packages\?????????\*.omg

	and probably any other file that starts with 
     30 80 (hex)


The basic format is quite simple from what I can make
out

30 80 marks the begining of an array

00 00 marks the end of an array

other markers
02	appears to denote an integer
04	is often a string (although it is also used 
         for large data entries such as the audio data
       
        in an omg file
06	again often appears to be a string although 
         not always
  
all entries then consit of two bytes.
	first byte is the type of the entry.
	second byte is the length of the entry

	the following bytes are the entry

for example
02 04 00 0F 42 40

	02 marks an integer
	04 says its four bytes long 
	00 0F 42 40 is the data (1000000 (dec))

the only variation to this scheme are when the length 
of the argument is 82 or 84 which declare that the
length term exceeds 1 byte
82 means the following two bytes are the argument
length
84 means the following four bytes are the argument
length

eg:
	04 82 4E 2B 4H 2D 2K etc.
		04 means its possibly a string
		82 says that the string length requires
                   two bytes to represent
		4E 2B is the actual length of the string (20011
(dec))
		4H 3D etc. is the data (of length 20011 (dec))


(note as 0x80 is 128 and the extension markers are 
above this it is probably safe to assume that all 
length parameters cannot exceed more than half of the
representational maximum (this would remove sign 
problems))


To test this idea I've knocked up a little parser 
that seems to work on all files I've tested it on. 
It just breaks the input file down into data types 
(which arn't always correct as Im not entirely sure 
what types 04 and 06 represent so it sort of guesses)

It should be attached to this lot somewhere
Usage: 
	java -jar omgparser.jar <infile> <outfile>

the output from the program has the following quirks:
	if a data type claims to be an string but is 
		longer then 128 bytes it will be tagged    
          as "Blob" (this occurs for the audio data
and 
	  xml data in .omg file)
	if a data type claims to be an integer but is
           longer than 4 bytes it will be tagged as 
           "Key?"


The .omg files therefore contain the following
information

Position (hex)
	{/begin array
		{/begin array
6			String	fopenMG	0x666F70656E4D47
f	const?	Integer	1003		03 EB 
13 see note*1	String	?????
0x010F500000040000008290B5D5CA84AD7A4BE288
29	const?	String	????		0x6701
2d	const?	Integer	16128		3F 00 
31	const?	String	????	        0x6801
35 see note*2	Integer	16896		00 00 42 00 
3b	const?	Integer	0		00 
3e	bitrate	Integer	132000	02 03 A0 
43	const?	Integer	384		01 80 
47	const?	Integer	0		00 
		}/end array
4c	???	String	??????
                0x68C0BF33C254145E (6 bytes)
5a	audio	Blob
5F3DD8E9033750F300000000000000007502F6117F08B716A6C59CA5F2083E9DB31A62F4C96A9273C132
EC406FB
	.....audio and training xml removed

	}/end array

NOTE*1
19-39	20 bytes
	OpenMG Content ID generated uniquely for each
        track exists at offset 0x13 in .omg files and 
        twice in the trailing xml as <pid></pid>
	
	it also exists in the MGData database
	in table	name	t_object
	field 	name	205
	
	the first 9 bytes appear constant 
	eg:  01 0F 50 00 00 04 00 00 00 
	and seem to be related to my copy ofOpenMG jukebox as

	this information exists in the file:
	Program Files\Common Files\Sony Shared\OpenMG
		\OMGKEY\omg_id.dat 
	which in my case contains the following:

	30 80 04 10 01 0F 50 00 00 04 00 00 00 00 00 B5 D5 CA
84 AD 00 00  
	
	compare this to a content id for a random track:
	01 0F 50 00 00 04 00 00 00 9F AC B5 D5 CA 84 AD 31 E3
04 0A

	removing the first four bytes from omg_id.dat
		as the first two (30 80)are the array
                   start mark and 
		the next two (04 10) say its a String 
                   of length 10.
	removing the last two bytes (00 00) which are
          the end of array mark and we are left with: 
		
	01 0F 50 00 00 04 00 00 00 00 00 B5 D5 CA 84 AD
	
	of which the first 9 bytes match content ids 
        for all tracks i have
	eg: 01 0F 50 00 00 04 00 00 00 

	the next two bytes are different for each track 
	(perhaps all four central bytes that are zero 
	can be different)
	eg:  9F AC 

	following these two varient bytes comes the 
        sequence:
	
	B5 D5 CA 84 AD	
	
	which match the bytes 11-15 in the content ids 
        (again for all tracks that I have)

	the last four bytes for the content id are 
        again different for each track
	31 E3 04 0A
	
	encoding the same wav file twice produces two 
	different content ids

part2 to follow with software


duftam


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com