ksandbergfl

On a different note, has anyone taken a look at the files in the EMDKEY folder? In my install of SonicStage, there are 4 folders, 001 thru 004. Each folder has two files, a CERT.DAT and a PRIV.DAT. The data in these files indicates that they are "permissions" or "privilege" for specific apps to use to be able to decode OMA files. 001 has the rights for SonicStage; 002 has the rights for Windows Media Player; 003 has the rights for IBM EMMS player; and 004 has rights for Liquid Audio Player. If you rename/trash the files in 002, for example - Windows Media Player can no longer play OMA files. I'm not sure what value this information is, but maybe it will give someone an idea of another way to decode OMA data in "faster than real-time", ala HIMDRenderer with local OMA files. I am wondering if a "virtual HiMD player" is possible.... that is, a software version of an NH600 that runs on the PC, and can play any OMA file and/or directly read the *.HMA files on a HiMD disk.

Here's a summary of my notes for the past week: The MACLISTx.dat files in the OpenMG folder are not required for OMA song playback... if these files are trashed, SonicStage will still play the OMA file,as long as it was created on that PC. This is not what I expected, but very handy to know. With this information, I did another test. I installed SonicStage on two PC's (PC1 and PC2). Immediately after installation , I copied the PC key (in the OpenMG/OMGKEY/omg_id.dat file) from PC1 to PC2, so both PC's had the same ID. I generated OMA songs on both PC's. I copied the OMA song (and all of it's related key info in the *.OPF file, MTDATA.mdb, etc.) from PC2 to PC1. As far as I could tell, all the pieces were there, on PC1, to make PC1 think the OMA file was created on PC1. However, PC2's song still would not play on PC1 (got the "invalid rights management info" message). All the songs created on PC1 would still play OK. So, that leads me to believe that there is additional key info, specific to each PC, that is somehow getting written into the OMA data itself. I am 90% sure that this info is in the OpenMG/OMGRIGHT/*.ICV files. An ICV file gets created for every OMA song during conversion. The ICV file is a 4-byte file. I think that these 4 bytes are inserted at various points inside the OMA file, as either a file marker or perhaps some sort of checksum. I need to do much more experimenting. First, I guess, would be to convert the same audio file on each PC, and do a byte-for-byte comparison of the resulting OMA files, and see what's different.

Note that the article states that Sony's OMA DRM scheme will be used on cell phones, video games, etc. Imagine "checking out" a song to a cell phone! What a mess.... Some hacker needs to get familiar with what the article calls "OMA Digital Rights Management 2.0 standard and with the Open Digital Rights Language (ODRL) version 1.1."

Found this article on DRM on ZDNet http://news.zdnet.com/2110-1009_22-5426747.html

I don't have a HiMD with recording (optical or line in), so I'm not sure... but I'm guessing that the HMA file you have is simply the raw ATRAC data off of the HiMD disk. I bet that Sony's upload flowchart is: #1. copy the raw ATRAC data from the HiMD onto the PC, into a *.HMA file #2. generate the OMA keys, etc. and build the OMA file from the ATRAC data in the *.HMA file. Since your PC crashed before Step #2 could be finished, you're kinda SOL. If you're handy with bits and bytes, you might be able to get away with this: #1. record another song on your HiMD. #2. upload it to your PC as normal. Let SonicStage create the OMA file and register it with SonicStage #3. Using a hex editor like WinHex or HexEdit, copy the raw ATRAC data from your HMA file into the new OMA file... overwriting the ATRAC data that's in the OMA file. I've had good luck doing step #3 with getting ATRAC data off the ATDATxx.HMA file on the HiMD disk... but I've never tried it with a 466MB file... plus I've never seen the *.HMA file you talk about. If the file is really really important, you could burn it to CD and mail it to me, and I'll see what I can do. Send me a private message if you're interested.

The OMG_ID.DAT file is the data that identifies your PC to SonicStage. It is the 20-bit key, without song-specific info. Take a look again at the 20-bit key in one of your OMA songs (or in the TRKIDXxx file). You will see your OMG_ID.DAT key, plus the song-specific info filled in. See the last byte? Say it's 5Ch. Search for a folder on your PC called "procfile". This is where SonicStage keeps all the key files for OMA songs that SonicStage has generated. Open the folder "procfile/5C". See the OPF file? It will have the same name as the key, ie 0105500040112233445C.OPF. The OPF file has all kinds of info... whether the original file was a WAV or a CDDA (CD rip) or an MP3, for instance. See bytes 0008h thru 000Fh? This is the song's MAC ID. These 8 bytes get inserted into the MACLIST.DAT files in the "OMGKEY" folder (same folder as the OMG_LOG.txt file). Every time you convert a song to OMA, another 8 bytes gets inserted into the MACLIST.DAT file at byte 0028h (which pushes the other bytes ahead by 8).... and the song counter at byte 001Ch gets incremented by 1. I assume the MCLIST.HMA files on the HiMD itself work similarly. >>warning<< You have to be very careful inserting bytes into the MACLIST.DAT files, or you will trash your SonicStage installation and have to start over. Finally, if you have Microsoft Access, open up the most recent MTDATAxx.dbf you find in the SonicStage folders. You will see all the SonicStage data for the OMA songs your PC has processed. I won't go into detail here, but you should easily be able to identify the OMA key info, the bitrate, etc. All these different files have to be "in sync" for SonicStage to play an OMA file. Any "hack" or utility that wants to copy OMA data, restriction-free, from HiMD (or to transfer OMG/OMA files from PC to PC) will have to factor in all of this.. plus maybe more that I haven't come across yet. I haven't had much time to hack around this week, but maybe on Friday I can make some more progress. I hope my contributions are helping you all out. Happy hacking!

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.

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.

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.

You are right -- It is seriously doubtful that Sony made the current HiMD units firmware upgrade-able. If Sony makes MD players that play MP3, I'm sure it will be a new line of HiMD models. Based on other threads around this site (where HiMD is a legally acceptable video recording medium), I anticipate future HiMD players that have small LCD video screens to play movies... these will probably be the units that also have MP3 support. Those of us "early adopters" of HiMD will be screwed. Maybe Sony will give us a $50 credit towards the purchase of the new HiMD players, but I wouldn't expect anything more.

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

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.

SonicStage writes a key in the "C:Program FilesCommon FilesSony SharedOpenMGOMGKEY" folder. When you re-install SonicStage, a new key is generated. The minidisc player still has the old key in it, and freaks out. Another sucky part of this is -- now, because your PC has a different key, the music on your HiMD disks is now "orphaned".... Sonic Stage will no longer let you "check in" or transfer the OMA files off the disk back onto your PC. SonicStage now thinks your HiMD's were created on a different computer, and that you are trying to illegally copy music to a different computer! If you didn't keep the OMA files on your PC (like I don't), you'll have to re-encode all your music AGAIN if you want to put it on another disc.

The file headers in OMA files are larger than in OMG. My guess is that Sony needed to add room for more metadata to support Connect. The XML tags in the OMA headers are also two bytes per character, instead of one in the OMG files. Again, my guess would be to support multi-national language character sets for Connect.

Yes, i've played around with that. The file format of the HMA file is pretty simple to figure out.... the raw OMA data is broken into 4k chunks and written into the HMA file, with tags at the beginning and end. It's easy to find all the pieces of a OMA song and string them together. One thing I've tried is: #1) create new OMA file using Sonic Stage called "blank.oma" to get a file with a proper "key" #2) use WinHEX to copy the hex data from the HMA data file into the "blank.oma" file... replacing/overwriting the data that was in the "blank.oma" I even got this to work!... once. I didn't take good notes and have had trouble duplicating my success. But once I get a process that I can duplicate repeatedly, I'll be sure to post my results. Maybe someone else can take this concept and find their own solution first.

The HiMDRenderer routes the WAV stream from the Sony OMA decoder DLL to a WAV file. That's exactly what I want to do with the tracks on my HiMD, when I play them with SonicStage. The only difference, as you point out, is that the HiMDRenderer is designed to work with a OMA file that is already on your PC. HiMDRenderer would need additional logic to intercept/re-route the SonicStage OMA decoder output.... I don't know if it can be done but I'm just curious.

I am wondering if the same principle that HiMDRenderer uses can be applied to another problem with HiMD --- I cannot transfer a song from HiMD onto any computer that the song did not originate from... my only option to get the song off of HiMD is to use SonicStage to "play" the song while recording the WAVE IN (the infamous "real time" method). These are songs that were written to the HiMD using SonicStage, not songs that the HiMD recorded via audio-ins. I had an incident where I transferred over 100 songs to my HiMD... then my computer crashed. I re-installed SonicStage, but since it's a "new" installation SonicStage thinks the songs were transferred from another computer.... and now all my OMA/OMG files are "buried alive" in my HiMD, with no hopes of escaping other than the real-time recording method. What I would *die* for is something like HiMDRenderer that would allow me to play a song from my HiMD, using Sonic Stage, but write the output to a WAV file *faster than real time*. I would think that GraphEdit (or whatever you used) to re-direct the output from the HiMD thru DirectX sound drivers could also be used to do this. Somehow, get SonicStage to think, while playing a HiMD song via the USB cable, that the DirectX driver is the sound card.... and write the data real fast. Is this possible? My fingers are crossed.....

My PC was 1GB is at work. Sound Recorder works for me, does what I need it to do, and there was no learning curve nor additional software to install. I'm at work and can't spend all day browsing the web looking for freebies, or installing non-approved software on a PC that belongs to my company. I can walk to any PC in the building (not that I would ever do so) and record internet streaming audio with no extra software anywhere. And I disagree that Sound Recorder is difficult to use... It has given me no hassles ever. That being said, I tend to agree with you - at home I am less encumbered. Being a musician I use Cakewalk Pro Audio to do this same thing. Do you approve of that? ;-)

If you have enough RAM in your PC, you can use Microsoft's Sound Recorder (it comes included with Windows) to record from WAVE IN. To record 30 minutes at a time, you would need roughly 300MB free RAM. Sound Recorder defaults to a 1 minute recording time.... but you can easily overcome this by: 1. record a 1 minute WAV file. Save as "1 minute blank.wav" 2. In Sound Recorder menu, click "Insert file" and select "1 minute blank.wav". Now, you have a 2-minute recording time! 3. Repeat this for as many minutes as you wish to record. I.E, do it 30 times and save the final file as "30 minute blank.WAV". Use Sound Recorder to open this file every time you need to record for 30 minutes. Your only limit is how much physical free RAM in your PC. A standard CD-quality WAV takes roughly 10MB per minute.... so, if you wanted to record for 30 minutes, you would need about 300MB free RAM.... 60 minutes would require 600MB RAM. I have 1GB RAM on my PC, with over 700MB free.... so I can record 60 minute's of music, using Sound Recorder, with no problems. You'll need another app, however, to split up the big WAV into smaller pieces. I use this method to record internet streaming audio. I'll record for, say 30 minutes... then I use a WAV editor app to split up the file into the indivual songs, as WAV's. Then I use Sonic Stage to move them to my HiMD, for listening in my car. It works for me... maybe someone else will like the idea too.

The 10.3MB is equivalent to 1 minute WAV file. Did you purchase GraphEdit or download a trail version? My guess would be that the version of GraphEdit you are using is limited to files of 1 minute in length. When you "Play" the OMA file, does it play all the way thru? Can you hear it thru your speakers? Does play also stop at 1 minute?

I use NiCad 700mAh batteries in my NH600. I get a good 10-12 hours out of them before I need to replace one. I just keep one or two extra charged ones with me. The majority of my NH600 usage is at work, so the NH600 is plugged into my USB port, and I don't need batteries.

Here's a company that makes bootable USB pen drives. Shouldn't be too hard to do the same with HiMD. http://www.embeddingwindows.com

I bought my NH-600D primarily for use at work as a portable, cheap media USB mass storage drive. I use it extensively since i got it 2 weeks ago. I am a programmer and now I have a real easy way to backup my work and take it home with me..... plus, it will play tunes in the car on my way home! I am connected to a USB 1.1 port, and see consistent 500KB/sec write times. That means a 100MB file will transfer to the Hi-MD in 200 seconds (about 3.5 minutes). Writing a full 1GB (970MB after formatting, actually) would take around 30-33 minutes. I haven't plugged it into a USB 2.0 port yet. I'll let you know what I find out. There is another post on some other thread here.... users have put video files on HiMD and played them back with no trouble. USB 1.1 can handle a DVD-standard MPEG2 video stream (which is roughly 4Mbits per second, or 500KB/sec). MPEG1 and DivX files should be no problem at all.