emeb

Last night I gave it a try. Here's my gear: iBook G4 800 w/ MacOS 10.3.9 MZ-NH800 Result: Softare installs & runs fine. When MD player is plugged in the app can see the tracks. Uploads of any format are impossible. Deletes are possible on unlocked disk. Rename may work. Regroup may work (didn't try). I wonder why PCM uploads aren't allowed on gen1 players? Eric

Did anyone notice in the MDcenter.nl review of the MZ-RH1 the comments on Mac compatibility? Looks like there's a chance that those of us with 1st & 2nd gen Hi-MD may be able to transfer music to them with our Macs. I'm waiting for the SW to show up this summer. Eric

Several options: 1) Avoid hardware that isn't supported under Linux. This is the only option for critical subsystems (video, memory, disk I/O, etc). Typically, critical subsystems will be supported within a few months of general availability. 2) Live with non-functional hardware until a driver is available. Possible with optional peripherals (webcams, sound, scanners, etc). This can take sometimes take years. Or never... 3) Dig in an write your own driver. I've done this and it can be fairly entertaining, especially if you're lucky enough to attract other hackers to help. Generally, if you're a Linux user (I am) you get used to checking these things before you put your money down, or you're shop at stores with a liberal return policy. In general I don't feel too left out, and for situations where there is no Linux support and never will be, there's always dual-booting to WinXX.

Dudes, A couple of comments: * Kudos to weissi for organizing an SF project. If you can collate all the data we've collected on the forums regarding HiMD in one place, that will go a long way toward making this goal possible. I've been pretty frustrated with trying to keep track of everything on the forums - they just don't cross-index very well. * Someone (I can't remember who) managed to get a debugger running that isn't detected by the 'DebuggerPresent' function and was posting some trace info a while back. It's worth a trawl through the forums to find out who/what/when. * I'm certain that the ATDATA??.HMA file and the OMA files are encrypted with 3DES CBC. The trick though is figuring out how to derive the key from all the various data fields in the TRKIDX??.HMA and hidden blocks on the HiMD disc. Once you know that algorithm, everything should be pretty simple. Finding that algorithm though will be a chore. Don't even dream of trying to crack 3DES. I don't have a lot of time for chasing this stuff these days, but I will be keeping an eye on it. emeb

I'm aware of endian differences and this isn't an endian problem. Looking at the data in a hex editor shows it is completely scrambled - not merely swapped bytes. The audio should be 16-bit silence which is long runs of data near 0 with minor variations +/- a few LSBs, but instead I see full-scale random values.

That makes sense in light of the things I noticed when hacking the track data. The M-series recorders don't apply as much encryption to the audio data in the ATDATA??.HMA file as do the 1st and 2nd gen HiMD units. The Mac WAV Importer app doesn't care what hardware _uploads_ the data, just what encryption was applied at the time it was recorded, so you can record on an M-series, swap the disc into a 1st-gen machine, grab the track on your Mac and still get a good upload. Encryption. DRM. Meh!

Good point. My guess is that figuring out the data flow during decryption is the first step. That will tell us how much data transfer is required, since some of the data transfer can be done with simple file copies, but other aspects (like reading the media id) will require custom code.

I can categorically confirm that decoding is not done in the player during upload. I've got USB sniffs of an upload session where the track data is clearly visible and identical to that found in the ATDATA??.HMA file - ie it's still encrypted as it travels over USB.

Sounds like a good theory. The disc id is probably combined with the various other keys in the TRKIDX??.HMA file and from that result the actual data blocks in the ATDATA??.HMA file is en/decrypted. So the big questions are: 1) What is the algorithm for computing the en/decryption key from the various media & track keys? 2) What type of encryption is used? The answers to both of these are buried in the code for those "skilled in the art" to recognise.

Thanks! I'll update my info.

OK - I tried setting that value to 0 on a track and the Mac Hi-MD Wav Importer allowed me to drag that track onto the desktop. _But_ when I opened the track up in an editor it was full of random garbage. Conclusion: 1st-gen MD recorders are applying some additional encryption that the M-series recorders don't do. The key for this process is in the TRKIDX??.HMA at offset 0x10 in the track info structure. If the key is 0, the Mac importer will see the track but will only properly import a track that was recorded on an M-series MD recorder. Oh well.

Yeah, a few of us have been hacking on those files too. Here's a link to the info I've compiled so far: himd_info.tgz May that will be helpful. Plus, if you find out anything useful, please feed it back to me for inclusion

I've got to apologize to the group - I tried to do some hacking on the TRKIDX??.HMA file this evening and found that the codec is not new. My analysis program had a bug that only showed up on my new 64-bit machine which caused the codec ID to be mis-labeled as unknown when in fact it is the same ID that my 1st-gen HiMD creates for an LPCM track. So, 0x80062807 is not new - I hope no one wasted any time because of this. I did a bit more digging and found some additional differences however: * Track 'Source' ID is 0 on the M-series, but was4DC28CCD on my 1st-gen. I tried hacking it to 0 on a test disc but the Mac WAV importer still didn't see it as valid. * Unknown data field at offset 0x10 is 0 on the M-series but was different for every track on my 1st-gen. I haven't tried hacking this yet. * Unkown data field at offset 0x36-0x39 was 0110B1B6 for the M-series but was 01055144 on my 1st-gen. I haven't confirmed that this field is constant for all discs however - it may be a media ID. So, there are still some avenues open for exploration, but the first report was in error. Happy Hacking!

Oh, that's just lovely! Looking at the overall complexity of SS I figured that they were on their game. Apparently they have blind spots too. Coolness. I don't know squat about WinXX software hacking (I'm a *nix geek) so it's great to have someone with experience banging on this stuff too. My biggest question is this: during upload of a PCM track from the MD recorder, what is the flow of data and what DLLs are invoked to process it.

That makes sense. Probably some sort of Diffie-Hellman exchange to set it up too. Wow - how did you nail that one? I've been searching for details on MagicGate for a while without any luck. Also handy to know. How'd you find it?