USB Sniffs of various MZ-NH1 actions.

[streaml1ne]

Found out the hard way today that I can only download tracks I record from an analog source to a single PC one time only. Needless to say this is LAME and Sony should fix it. However, someone might be interested in doing it for them =)... rapidly... To that end I made some USB sniffs of traffic through various actions on my NH1 which may or may not help.

http://canopus.syphen.net/hi-md/mz-nh1-usbsnoop.zip

contains a zip file with the logs I got from the usbsnoop program located here:

http://benoit.papillault.free.fr/usbsnoop/

Now for the files...

usbsnoop-connect-noSS.log

Is of a connection and subsequent disconnection of the MD to the PC without SS2.2 open beforehand. I waited until Windows decided to auto run the MD and pop up an explorer window. No other actions taken.

usbsnoop-connect-SS.log

Same procedure but with SS2.2 open beforehand, notice the size difference. Note also that SS2.2 only downloaded the list of stuff on the MD (80 minute MD in HiMD mode). There were no other actions taken inside SS2.2.

usbsnoop-connect-upload1-SS.log

SS2.2 Open prior, connect, convert and upload a single track, disconnect.

usbsnoop-connect-delete1-SS.log

SS2.2 Open prior, connect, delete previously uploaded track, disconnect.

usbsnoop-connect-copyfile-noSS.log

SS2.2 closed, connect, wait for an explorer window, copy a 2.9 megabyte file to the MD, wait for the recorder to settle down, disconnect.

usbsnoop-connect-deletefile-noSS.log

SS2.2 closed, connect, wait for an explorer window, delete the file, wait for recorder to settle down, disconnect.

These files are sparse in that there's alot of what I'm guessing is USB background chatter in them. I haven't dug too deeply into them as yet, I wanted to get the files posted for people to look at. The data is there, let's get the party started...

-stream

Edited January 20, 2005 by streaml1ne

[Bananatree]

Thanks for your help.

You should remember that Sony legally cannot allow people to make digital copies of digitally copied copywritten work. It's called SCMS.

[streaml1ne]

Thanks for your help.

You should remember that Sony legally cannot allow people to make digital copies of digitally copied copywritten work. It's called SCMS.

I'd be fine with Sony limiting recordings made from the optical in since this is likely from a copyrighted source, but in my case the recording was a regular analog 1/8" in record from a dat of a conference. I own the rights to the original recording. Seems wrong that Sony can limit my usage of the digital copy, especially since they know the source line was analog (mic also applies here). It's really damn annoying in my case, because I want to use MD for archival onsite at conferences instead of bulky and expensive dats, but workability back in the office is important as well. It's a hell of alot quicker and easier to download the track and decode with himdrender than it is to re-record in realtime. In this scenario the minidisc IS the archive point. We can just store the small disc with any associated conference data (powerpoints, etc) for future use. With the DRM limits I'd have to download and archive to CD or a fileserver just to have quick re-use capability in the future. It's a costly added step, both in time and money, and it's just a nuisance.

[sknight]

It's only a matter of time before someone figures out how to defeat the SCMS.

[dex Otaku]

It's not SCMS. It's proprietary DRM which does not exactly follow SCMS since there are more rules added to it than just "original", "copy", etc. It's not just a couple of bits, it's an entire filesystem more or less, including encryption.

Note that at this point, the SonicStage still trashing tracks issue is still present. If what you're copying isn't in at least duplicate before you do the upload/convert cycle, you are risking losing it. Period.

[jadeclaw]

I'm more interested in resetting the upload counter, so if anything goes wrong with the Library despite a backup,

that I can rebuild it from the MDs.

And of course other tricks as well...

I'll have more time next week, then I will take a close look here.

Thanks streaml1ne for the work.

[marcnet]

Just a thought: If the protocol is there to extract encryption keys from the device, and the actual music data can be read from the big .hma file, then you have your own .oma file maker.

This could make my HIMDRenderer program even better :smile:

But... Im not promising anything - just that Ill have a really good look at some point in time.

[dex Otaku]

Just a thought: If the protocol is there to extract encryption keys from the device, and the actual music data can be read from the big .hma file, then you have your own .oma file maker.

Or for that matter, a way to bypass making .oma's altogether, as well as the upload counter.

[streaml1ne]

I'm more interested in resetting the upload counter, so if anything goes wrong with the Library despite a backup, 

that I can rebuild it from the MDs.

And of course other tricks as well...

I'll have more time next week, then I will take a close look here.

Thanks streaml1ne for the work.

Yes, this would be fine by me and I see no reason why Sony could not make newer versions of SS do this for analog line in or mic recorded tracks. The upload counter should be unlimited for these tracks.

[streaml1ne]

On a side note, I flipped the write protection tab on an MD. SS won't even try to upload tracks from the MD to PC with it armed. Not too suprising. I just haven't seen anyone try it and figured it would be a good test to see if you could prevent SS from deleting the tracks that have no more copies available.

[fuz]

i was going to do some more work and get some more coherent thoughts together but seeing as some of you are also playing with this stupid upload restriction..

If you record something and then upload it, i've noticed that the following files get affected :

ATDATA incremented but its not different to the old ATDATA file

MCLIST, TRKIDX incremented and changed

(i'm just running a plain old diff on them to see if theyve been modified)

assuming youve just formatted a disc and recorded one track onto it and then uploaded it, open up TRKIDX02 and TRKIDX03 in a hex editor. Head to 0x809E and note that the old TRKIDX has the code 08 03 while post upload its 44 00 post upload.

Change it back to 08 03 (actually, i'm not sure if 0803 is a special sequence because i just put random things in like 09ff and it also thought i could upload) and SS thinks its uploadable again.

But.

When you actually do the upload? It dies.. and the most annoying thing is how it dies.. it transfers most, if not all the data across, dies and doesnt create any track data on the PC. Bah. It also does interesting things like fails to play on the device anymore and generally not work for that track.. perhaps this may be enough if the data transferred across is complete enough so that you can somehow invoke the MDupload->OMA translation outside of sonicstage.

If you start trying to hack the MCLIST file, pretty much any change and the whole disk becomes unusable and needs to be reformatted (or you need to recopy the original stuff back).

Other things : i'm having absolutely no success cloning discs so far.. of course i'd assume this would be protected against but it kinda implies theres a region of the disc i'm not seeing, cant access and that it contains some kind of important checksumming or state type data.. What i dont get is that if this is the case, why would you even bother having any form of track control information exposed? If you are restricting access to a certain fixed-size segment of the disk then why not just bundle the MCLIST/TRKIDX files into that area (fixed size, control information) and leave us only access to the ATDATA file (variable sized but encrypted)? This way anyone using the disc as a general storage unit wouldnt be able to overwrite anything important..

The only things i can think of are that either that the engineers at sony are

- More clever than i am (probable)

- Crazier than i am (unlikely, but possible)

or that

- theres a flaw in my cloning/restore procedure (unlikely, i can make an image and then immediately restore that image so i'm probably not breaking anything)

- theres a good reason for keeping as much as possible visible to normal filesystem operations. (possible, but it still seems odd to me)

Anyhoo, its late. Apologies if some of that didnt make sense.... yell and i'll tackle it again tomorrow

[dex Otaku]

But.

When you actually do the upload? It dies.. and the most annoying thing is how it dies.. it transfers most, if not all the data across, dies and doesnt create any track data on the PC. Bah. It also does interesting things like fails to play on the device anymore and generally not work for that track.. perhaps this may be enough if the data transferred across is complete enough so that you can somehow invoke the MDupload->OMA translation outside of sonicstage.

What's interesting about this is that that is an exact description of the SS upload bug that trashes tracks.

[streaml1ne]

Other things : i'm having absolutely no success cloning discs so far.. of course i'd assume this would be protected against but it kinda implies theres a region of the disc i'm not seeing, cant access and that it contains some kind of important checksumming or state type data.. What i dont get is that if this is the case, why would you even bother having any form of track control information exposed? If you are restricting access to a certain fixed-size segment of the disk then why not just bundle the MCLIST/TRKIDX files into that area (fixed size, control information) and leave us only access to the ATDATA file (variable sized but encrypted)? This way anyone using the disc as a general storage unit wouldnt be able to overwrite anything important.. 

Has anyone tried connecting a HiMD unit to a linux box? I know FreeBSD doesn't see it as a raw disk device, but it does see something. If linux does you might be able to clone the device directly with dd. Something like:

dd if=/dev/<usb disk device here> of=/tempfile

pop in a new disk and do the reverse

dd if=/tempfile of=/<usb disk device here>

That might grab whatever raw data is missing on the clone, though if Sony is obfuscating things on MD hardware itself then you're SOL.

[doclloyd]

i've connected it to my linux notebook before and it works well enough. haven't tried what you've mentioned yet, but i will when i have the chance...

[fuz]

What's interesting about this is that that is an exact description of the SS upload bug that trashes tracks.

I had a thought about this myself later that day, in my playing around with the files i tend to break things a *lot* but i can always revert back to the original files i've got backed up here on the PC side and essentially undo my mistakes.

My thought was that if the transfer dies just before any of those important, state changes are made to the disc (ie: changes to this hypothetical protected region) then you could still protect yourself by copying the entire disc to your HD pre-transfer.

Then if anything screwed up you'd just be able to reimage it to its original condition and try again.

(of course if it borked up post-updating the internal state stuff then this isnt going to help..)

[streaml1ne]

i've connected it to my linux notebook before and it works well enough. haven't tried what you've mentioned yet, but i will when i have the chance...

Heh BE CAREFUL. dd can be dangerous :grin: It should create a perfect bit for bit copy provided Sony's not doing something funky on the MD hardware. Come to think of it what does linux label the raw disk device as when you plug in your MD and have you tried mounting it?

[doclloyd]

I've mounted a Hi-MD disc w/o incident. It labels it as /dev/sda (scsi-emulation)... just like other usb drives. Once I'm at home I'll try out the dd command when I get home from work.

[streaml1ne]

So how'd the dd go? Has anyone started looking at the USB sniffs? Hopefully I'll have some time this weekend to get into this a bit more.

[poorlyconditioned]

Hi there.

Well, I tried the "dd", and it doesn't work!

Take a known good (audio) disk. Standard MD formated as HiMD.

Input with dd. Output to a new disk.

Result: "CANNOT RECORD OR PLAY"!

Here are the details. The only informative thing is I have measured the

read and write times. Read, approx 4Mbps. Write, approx 1.25Mbps.

That sucks too. Maybe I can change blocksize or something.

OK, I'm hoping someone can hack this filesystem!

Richard

-------------

[root@tapir root]# time dd if=/dev/sda of=md

597492+0 records in

597492+0 records out

305915904 bytes transferred in 585.245410 seconds (522714 bytes/sec)

real 9m45.265s

user 0m0.340s

sys 0m7.230s

[root@tapir root]# time dd if=md of=/dev/sda

597492+0 records in

597492+0 records out

305915904 bytes transferred in 1962.494781 seconds (155881 bytes/sec)

real 32m43.191s

user 0m0.610s

sys 0m6.230s

[streaml1ne]

Did you or can you try mounting that 'md' file on a loopback device? I wonder if it keeps the filesystem intact.

[ksandbergfl]

Did you or can you try mounting that 'md' file on a loopback device? I wonder if it keeps the filesystem intact.

I've been working on this too (without much success), and I'm wondering if MD's have a "serial number" encoded somewhere on a read-only portion of the disk. CD's have something similar, I believe, so that My theory now is that the MD uses the S/N of the disk itself as part of the "key" to decrypt the 128-bit keys generated and placed in the MCLISTxx file everytime the MD is written to (new songs are added, deleted, etc.). The HiMD firmware must somehow use the MD serial #, match it up with the disk ID stored in the MCLISTxx file at bytes 76 thru 79, and use that to decode the 128-bit keys stored in MCLISTxx bytes 16 thru 31 and/or bytes 96 thru 111.

[ksandbergfl]

Just a thought: If the protocol is there to extract encryption keys from the device, and the actual music data can be read from the big .hma file, then you have your own .oma file maker.  

It's relatively easy to go thru the ATDATxx.HMA file and piece together the ATRAC raw data into an OMA file. I have done it manually with a hex editor, and when I find time will write a little program to do it.

The trouble with OMA files is -- if the OMA file did not originate (was not encoded) on your PC, it still won't play. Try copying an OMA file encoded on your laptop to your desktop, then play it with SonicStage to understand what I mean. Sony really, really, really doesn't want people to copy music! Simply "extracting the encryption keys" from the HiMD device won't do you any good for creating an OMA file.

In my testing, I have learned that you have to use SonicStage to create a "dummy" OMA file first (so all the keys and other DRM stuff are generated by and exist on your PC), then you can take the raw ATRAC data (for a particular song, of course) from the ATDATxx.HMA file and insert it into the dummy OMA file (overwriting/replacing the bytes in the dummy song). I get this to work every once in a while... I still don't understand why it doesn't work 100% of the time, but I hope to figure it out soon.... maybe this posting will give someone else more ideas too...

[fuz]

I've been working on this too (without much success), and I'm wondering if MD's have a "serial number" encoded somewhere on a read-only portion of the disk.  CD's have something similar, I believe, so that   My theory now is that the MD uses the S/N of the disk itself as part

I kinda agree with you here but there has to be something slightly more to it as even if you image the same disc, do something to it and then try restore the old image back it wont let you so there has to be something other than a straight out key.. This would stop you from duplicating the information to another disc but wouldnt (alone) stop you from breaking the 1-upload restriction.

Also, i was doing some tests earlier, if i upload a file, take a copy of the MCLIST file off the disc, format it and upload the same file again, the MCLIST data changes. However, if i take another disc, format it and then upload the same file, i get a different MCLIST (expected) but the ATDATA file is the same.

My current theory on this is that the MCLIST is the control file which has all the important data in it (like checkout counts and all that stupid DRM info) . If it contained fragments of a decrypt key then shouldnt the ATDATA file change if the MCLIST file changes?

[fuz]

It's relatively easy to go thru the ATDATxx.HMA file and piece together the ATRAC raw data into an OMA file.  I have done it manually with a hex editor, and when I find time will write a little program to do it.

I've been toying with this here, have you been trying to figure out how to make the 2144 byte header or have you been just replacing the raw ATDATA? Also, have you been just replacing the entirety of the data or have you tried extending/shrinking file lengths?

[ksandbergfl]

I've been toying with this here, have you been trying to figure out how to make the 2144 byte header or have you been just replacing the raw ATDATA? Also, have you been just replacing the entirety of the data or have you tried extending/shrinking file lengths?

i started there too.. creating my own OMA header. But if the key info in the header wasn't generated by Sonic Stage, you're kinda out of luck.

I keep the header of the "dummy" OMA file and just replace the rest with the raw data from the ATDATA file. I *have* gotten it to work once or twice, but it hasn't been consistent enough for me to duplicate at will.

[ksandbergfl]

Also, i was doing some tests earlier, if i upload a file, take a copy of the MCLIST file off the disc, format it and upload the same file again, the MCLIST data changes. However, if i take another disc, format it and then upload the same file, i get a different MCLIST (expected) but the ATDATA file is the same.

My current theory on this is that the MCLIST is the control file which has all the important data in it (like checkout counts and all that stupid DRM info) . If it contained fragments of a decrypt key then shouldnt the ATDATA file change if the MCLIST file changes?

Yes the MCLIST contains the DRM info. Everytime the music data is written to (using SonicStage or SmartBurner), new 128-bit keys are generated and put in bytes 16-31 and 96-111. The "disk ID" info in bytes 76-79 never changes. The identifiers for the songs are 4 bytes each and start at byte 112. My current theory is that HiMD uses the 4 disk ID bytes, plus the disk serial # (or some other info in a hidden area of the disk), as the part of a key to validate that the 128-bit keys aforementioned are valid and can be used to decode the music.

[ksandbergfl]

Just a thought: If the protocol is there to extract encryption keys from the device, and the actual music data can be read from the big .hma file, then you have your own .oma file maker.  

.

Did more testing today... basically blew off work and hacked away at this.... sshhhh, don't tell!

I discovered that the OMG key info is stored in the TRKIDXxx.HMA file, starting at offset 8080h. Take a look. The key for the first song will be at 8080h, and goes for 20 bytes. The key for the 2nd song will be at 80D0h, and goes for 20 bytes. The key for the 3rd song is at 8120h and goes for 20 bytes... etc etc. Every 80 bytes there is a new key. XX number of songs would mean XX number of keys.

I have successfully done the following:

#1. create dummy OMA file on my PC using SonicStage. Length doesn't appear to be important.

#2. Extract key for desired track on HiMD by method described above. I used track 2 so I got the key from TRKIDXxx.HMA at offset 80D0h.

#3. Using WinHex, I took the 20-byte key and overwrote the key in the dummy OMA file. The key goes into the OMA file at offset 040Ch.

#4. Manually (using WinHex), I identified the data blocks that belonged to track 2 in the ATDATAxx.HMA file. I stripped off the block headers and stuff to get just the raw ATRAC data. I then pasted the raw ATRAC data into my dummy OMA file at offset 0458h. Save the dummy OMA file.

#5. Disconnect HiMD unit from PC.

#6. Click on dummy OMA file to launch SonicStage. Song from HiMD is playing!!

Note that I didn't need the MCLISTxx.HMA file at all.

There ya go. Now I finally know how I can "rescue" my songs off my first HiMD disks that got orphaned when my PC crashed. Of course, it means I still have to create a "dummy" OMA file for each song I want to get off the HiMD first, and I still need SonicStage... so it's not a effort-free endeavor.... but at least I have proven (and repeated consistently) that it can be done.

I'll try to make some more time to write a reader/parser app to process the ATDAT and TRKIDX in a Windows GUI, to make things easier.... unless some sharp programmer beats me to it.

Have a great weekend.... time for me to head home.

[dex Otaku]

This is good work, you guys.

[marcnet]

Ill get right on that. If my program could bypass the sonicstage rubbish totally... I think my program would be more usefull

Oh.. and track names seem to be at 0x40010

[?eter_]

This is cool :smile: My prospective HiMD purchase is looking more and more attractive everyday. Sony have their heads filled with so much DRM rubbish that they can't see how powerful MD is as a recording medium for musicians. I'm glad that before very long we will have ownership of our own recordings,to upload/download/transcode as we please.

Keep up the good work guys.

?eter

PS. funny how they begged to have their entire encryption system broken through 2 things: not supporting Linux, and having a buggy tool that trashes tracks.

[xispe]

GREAT NEWS! This could lead to many improvements!

[fuz]

Playing around with the TRKIDX files tonight, offset 0x30108 has the location of some track length data :

0x30108 - start position (word)

0x3010a - end position (word)

where both those numbers are in blocks of ATRAC data (a block being 16384 bytes long)

the word at 0x3010c i'm still a bit unsure about. It doesnt change for the same track uploaded or its copies but does change for a new track. By shrinking this number the track length changes (very minorly) in the range of about 1 sec/-16 from the number. I'm guessing its to do with the last ATDATA block being partially empty (the fuller the last block, the higher this number). I've not had any problems playing them if i reduce them by a moderate amount but radical changes cause things to be unplayable.

Also, i've also found that while i can make changes that are playable in sonicstage, sometimes they will cause the player itself to refuse to play. An instance where sonicstage is more robust than something else? Bizzare

[marcnet]

Have you tried this with recorded material? IE: Taking audio data that was recorded and has not yet been uploaded via SonicStage?

It seems that the data from a LineIn/MicIn recording in the ATDATAXX.HMA file differs completly to the data in the resultant uploaded OMA from SonicStage.

The only thing that hasnt changed is the key at 0x40c (or 0xc0c in the case of uploaded OMA files).

Its as if SonicStage is reading and decrpyting data from the HIMD, re-encrypting it and then storing it as a OMA file. The decryption key is then stored in Sony's DRM database.

I think thats why SonicStage wont upload the track the second time. Its stored the key from the first upload (whether its trashed it or not). When you try to upload a second time it searches and finds the tracks key in the DRM database. It then knows that its already been uploaded, so proceeds to delete the track instead.

Unless im doing something wrong, it looks like its going to be very difficult to bypass the SonicStage step. In order to this recorded audio data from the ATDATAXX.HMA file will need to be decrypted (and possibly re-encrypted) manually.

Anyone good at cracking encryption?

[fuz]

Have you tried this with recorded material? IE: Taking audio data that was recorded and has not yet been uploaded via SonicStage?

Dammit.. i just did the same test myself and i can confirm similar results. Why in GODS name is there so much obfusciation around recorded material?!

*grr* its almost like they've gone and copyrighted my own recordings and severely limited what i can do with them. If i was in a more annoyed mood i'd suggest thats bordering on illegal and would warrant me filing a formal suit againt Sony

Unfortunatlely, because of this i've no longer any ideas on how to bypass sonicstage.. i do have ideas on how to neuter the 1-upload restriction however... its painful and complex, but you'd have to upload, render to wav, import (to get it into a 'normal' OMA) and then dump to MD.

Theoretically, you could then use the old copy-blocks-of-data method to get things off the MD at that stage..

I think thats why SonicStage wont upload the track the second time. Its stored the key from the first upload (whether its trashed it or not). When you try to upload a second time it searches and finds the tracks key in the DRM database. It then knows that its already been uploaded, so proceeds to delete the track instead.

Ooh, heeey.. idea. If the upload is trashed (theres no .oma on the pc) then theres only one place where the track info is stored - the access DB files (i assume since it looks like each .oma has its own little DRM package embedded into ti). If so, could we not just rip that data out and hopefully theres a mismatch and sonicstage will avoid deleting the data entirely?

(y'know the oddest thing about all of this? The way it seems to have been implemented and this work we've done makes an HiMD unit a viable choice for music piracy since all you'd do is take it over somewhere, rip tracks to disc, come home and 'import' using the abbreviated method. But you couldnt do this for any of your own personal recordings, oh no, thats locked down well and truly. *gah*)

[fuz]

More misc info, i've moved to trying to learn a little more about the OMA files, i'd like to know why certain things do and dont work.

First things, theres two or three file headers it appears, an 'ea3' tagged one at the start of the file and lower down an 'EA3' header. (who'd like to bet EA3 stands for encrypted AtTRAC 3? ). The 2nd header i'm considering the actual data payload and you can replace this block at will with data from another similar OMA file.. the upper 'ea3' group can also be *heavily* corrupted (i overwrote stuff with nulls) and things still play.

The third file header is embedded near the top, theres the string 'EKB' and a block of data. This wouldnt have twigged my interest all that much apart from the fact that on your discs, the file 00010012.HMA also appears to be the same kind of data..

Also, in the OMA file near the EA3 block theres a err, 4 byte group that defines the data type. ATRAC3/+ and bitrate.. i forget where it is but it's pretty obvious once you have a look at a few files side by side.

I'll post some offsets later when i get back in to my main PC..

[streaml1ne]

Ran across something interesting tonight. A few days ago I was playing with the data side of the NH1 and I formatted a HiMD in Windows Explorer. Tonight I went to use that disc for music and SS complained that it had been formatted outside of SS and needed to be initialized. So I initialized the disc within SS. Then it pops up a window that mentioned rights info that may have been on the disc and how SS was going to recover the information and apply it to files in my library. It mentioned that any affected file's transfer count would be adjusted in my library. *shrugs*

[Rowan]

So that seems to indicate that the 'invisible area' can't be touched by even a WinXP OS format. Has anyone tried a format with a Linux disto?

[fuz]

I'll post some offsets later when i get back in to my main PC..

Do a search for the EA3 header (should be aligned on boundaries of 0x400) and from there, the offset is 32 bytes. Codes i've got so far are :

01 00 28 22 : AT3Plus 48kbit

01 00 28 b9 : AT3Plus 256

00 00 20 30 : AT3 132

04 00 29 00 : PCM 1411

( i wasn't patient enough to find out the others )

However, you can set the 4th number to something rather arbitrary in the case of AT3+ (this is all i've tried) and watch as sonicstage tells you youve got a 352kbps AT3+ file (code : 010028ff). I wish

Anyhoo, more on this, the EA3 block is definetly the payload section, i've done some mega corruption of the ea3 block and i swear, theres a lot of redundancy there...

The theorised 20-bit key does indeed appear to be critical as if i tamper with this in any way things go pear shaped and i get told to download lisc info. Feh.

Interestingly enough, if i put in a valid keyset here and sonicstage just fails to play anything, its almost certainly an ATRAC decoding problem as opposed to decryption, i think (try setting the code to say its AT3 data instead of AT3+ and you get an identical fault.. this is why i'm supposing the ATRAC decode bit breaks). Set the datacode to PCM and youll see what i mean, you can take the key out of TRKIDX, patch it in and get it decrypting. You will however, get out a whole lotta static..

Hey, at least its a step up from files not playing

[fuz]

(note : scuse the long post..)

You know you're not having the best day when you trash your enitre sonicstage library accidentally..

Of course when i say 'accidentally' i lie. I was doing some work on OMG keys and whatnot.. basically, i took a backup of my database and had a look at what got stored (the theory being that if i found out what got stored i could then extrapolate as to whats important or not).

Anyhoo, to cut a long story short, theres this teensy little file called 'omg_id.dat' in the omgkey directory which just happens to have data thats found throughout an OMA file.

Neat says i and proceeds to modify it to prove it really is important. Voila! All tracks now demand i go and get a proper licence for them. Woot!

I now change back the data and restart SS to listen to some music while i ponder ways of manipulating this.. and my tracks still demand a licence.

Gah.

Also, whats REALLY annoying is that theres this file in the same directory called nc_ea3topcm.ocm... all i wanna do is that and theres the filter, staring me in the face *sniff*

oh, and lastly for tonight before i scream at the PC some more, you know how we always complain sonicstage fails overly silently? Well, go to the "C:Program FilesCommon FilesSony SharedOpenMG" dir (should be the same on all PC's as this one isnt user defineable) and open up the omglog.txt file. Still terse, but it confirms a few things i thought i was doing. I think the funniest message so far is this one :

2004/11/04 01:43:55 [C:Program FilesSonySonicStageOmgjbox.exe] 00000aac:00000a64 OMGException: (0x302)<28258> - OpenMG oh my god!

I'm almost of the mind that it'd be worth (re)learning win32 programming so i can try use these neat little dll's and other preprogrammed chunks lying around...

[marcnet]

Most of the DLL's are COM based. So you'd have to know the exact interface ID, class ID, and Interface function pointer structure to use them.

Oh and realtime debugging wont work. Sony have seen to it to crash any program that happens to be using one of their DLL's under a debugging session.