fuz

I ran through JB here in perth just the week past and saw HiMD blanks, no idea what their stocking levels are, but they are somewhat accessible here (yay!)

I'm also sorta at an impasse.. but thats me being busy doing other things (do you know how hard it is to pack one's worldly belongings into just 20 kgs?). Only thing i've had a chance to play with is the EKB stuff (theres a directory with .ekb files in it) and all i've done is made sonicstage incapable of using HiMD media.. eheh.. oops. I think the weirdest/not-so-goodest thing i've noticed is how uploads work, it seems to transfer the data (and all relevant keys/data/ident/whatever) to the pc, munge things on the MD and then do a big conversion thing on the PC side. I really hope that conversion step isnt critical as its something not easily duplicable by simply copying bits around..

(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...

I'm hoping to someday work out enough of the DRM/HiMD formatting to be able to patch in raw PCM data.. mm.. 1 gig discs of raw goodies playable on the unit My holdover plan however is to use HiSP for something i can listen to while out and about but also to have a full blown CD image on the rest of the 1 gig disc so when i get to a PC i can listen (or process) to that directly. Not having 1 gig discs however has been a bit of an impediment to this.. :rasp:

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

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..

I dont know about the 4p/4s's but i've a set of er-6's here (blessed relief from that annoying drone on plane trips) that do ok out of the nh9000 if that helps as a reference. More subjective comparisons on motor noise.. when it's seeking its not quiet at all. Background noise here is my notebook fan (a p5020) running kinda idle and me clacking away on the keyboard. The fan is a low hum (very low) and the nh900 seeking is only marginally more noticeable than my keyboard clacking..

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.. 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*)

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

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 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?

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..)

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

I'm going to have to respectfully disagree as a group != an album. Both groups and albums are collections of tracks but its possible for an album to cut across multiple groups. in one line : where it says 'Album' on the disc, in sonicstage it says 'Source'. (but really means 'Album') in more than one line : Looking at it another way, a group is a logical collection of tracks on the disc (this group contains tracks x,y,z) while each track has a note saying which album it belongs to (track x is from album q). An exampe is a Little Birdy CD i've just dumped onto my NH900.. its in the group called "Big Big Love" and the source of all the tracks is "Big Big Love". If i head into sonicstage and create four new groups (fish, fowl, cubes, squares) and place random tracks in each i can now use the group seach/navi mode to navigate across each group while if i use the Album mode then theres still only one album - "Big Big Love". If i was to then go and pick the singles off the CD and rewrite the source for these tracks as 'Big Big Love - Singles' but not touch the groups, my album lists now reflect two albums and the four groups. Did that make any sense? Its 1:30 am here, blame lack of sleep on any lack of coherence

if it's any help, i tossed around something very similar like this for my N10.. the connector has like, a dozen pins of which i managed to figure out what they were. The battery box also has the same connector, so i slid back the plasticky sheath and read out the voltages.. there was a 1.1v connector and a 6v connector from memory along with the four USB pins (gnd, +5v, data1, data2) If you plugged it into the PC via the USB cable and crossed the 5v and 6v pins (thus sorta powering it..) you'd get the red charging light and battery charging indicator. I know i know, its somewhat crazy, but it seemed to work.. I *was* going to make a permanent mod and do some other things, but i got an NH900 instead. The point of this is that if it was possible on the N10, i'm sure its in the same vein as the NH1... interestingly enough, this was one of the reasons i instead went for the NH900 as its part of my mobile rig. Cradles arent mobile.

Looking at this in a slightly different way, you could just store a bunch of mp3's on the disc in data mode and access those directly? ie : treat the disc as a datastore.. Along these lines, I've started putting episodes of astroboy and other small random episodes of stuff on a few spare disks i have. Its actually in an attempt to reduce power consumption on my laptop for flights and things like that.. i'm betting the md unit sucks less power (via usb) than your average notebook hard drive does but i'm testing that theory out now. If i get hold of 1 gig blanks then i can stuff a movie onto a disc.. now that would be fun

*sniff* i'm going to miss him, but its time for me to part with my beloved N10 (its about 2 years old now). Of course i did just give in and get a new NH900 so i'm not done with MD kit quite yet I figured i'd post here first since its got better odds of going to a good home via here than elsewhere. In the package would be pretty much everything you would expect : one N10 in relatively good conditon. One scratch near the end search button, minor scuffing on the LCD display bit and general wear (like the chrome finish wearing off the plastic). It still looks better than the nh900 though an RM-MC33EL remote (minor wear here too) & earbuds set 6v battery charger (UK-style plug) & dry battery case Sonicstage 1.5 CD (but why in gods name you'd use 1.5, i wouldnt know) USB-MD cable, digital cable and small black velcro pouch 6 x 74 min blanks. 3 unused, the other 3 are pot luck as to what i leave on them .... but NO n10 cradle. I lost it when i was in london (long story, but suffice to say i was not impressed with myself) and i've been just using the usb cable instead since. It'll also not be the original box and whatnot as that's been lost long ago. I'd like to get about 75USD for him, but i'm open to (reasonable) suggestions. One thing to note : i'm in perth, western australia.. any package should be light though so shipping shouldn't be overly onerous. Feel free to hassle me here or email me at : fuzzy at greenworm dot net if youre interested at all.