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?

Thanks Dale, I've grabbed the zipfile and run a quick analysis on it. Sony has indeed defined a new codec for the M series recorders (0x80062807), although the audio data in the ATDATAXX.HMA file is still encrypted and flagged as LPCM. It might be worthwhile to try hacking on a 1st/2nd gen HiMD disc to see if changing the codec id will allow the Mac application to download it. I'll try this later and report back.

Precisely! When you plug your MD recorder into the Mac, you'll see a new folder appear on your Mac desktop. On my Mac with an MZ-NHF800 it's called 'NO NAME'. Open the folder up and you'll see another folder called 'HMDHIFI'. That's the one I want a copy of. If you haven't installed a zip application, you can still do it from the MacOS X Terminal. First, copy the HMDHIFI directory onto your Desktop. Then, open the Terminal app (in the Applications/Utilities folder), and simply type the following commands: cd ~/Desktop zip -r files.zip HMDHIFI That should create a zipfile called 'files.zip' on your desktop. Then just stash it on a website and post or mail the location, or just mail it to me at the address above. Possibly, but it may also be that the M series mark their PCM recordings with different values of ID flags in the track index file, and/or different types of encryption. That's why I'm interested in digging around in the data files. Let me know if you have any questions about the process Eric

Dale, If I infer correctly, you have an MZ-M10[0]. If this is true, could you help me with some research please? I like to dig around in the binary data files for details of how the track data and formatting is encoded and it would be very interesting to look at how the M-series recorders flag their data. What I need is to get a copy of all the files in the hmdhifi directory for a disc with a few short tracks (< 1second - no particular sounds necessary, just silence is fine). If you could create a disc with a few short PCM tracks, zip up a copy of the hmdhifi directory & contents and put the zipfile somewhere on the web that I could get to (or email it to me @ ebrombaugh at earthlink dot net) that would be really helpful in figuring out how these new players work. I'll document what I find and post the details on this forum. If we're lucky we may learn something useful. TIA Eric

Thanks for posting this. I tried it out on my system with following components: Mac G4 iBook w/ OS X 10.3.9 MZ-NHF800 Memorex clear 80M disc formatted as HiMD 300K Recordings done in PCM from microphone input Result: Installation went just fine. Application runs and sees MD when attached via USB. Track titles/lengths appear in application window but are greyed-out and cannot be selected or uploaded. There's a second application which was installed called HiMD Monitor. It won't run when double-clicked in the finder. Anyone know what this does? Oh well. It would be nice if they would have let us use this with older HiMD devices.

I haven't tried altering the fields to see, but others have reported on this elsewhere in the forums. Generally, it seems that there are checksums involved and if you change any of the values in the trkidx??.hma file then SS will delete the track next time you try to do anything with it.

I've been poking around in the guts of the Hi-MD file data. Here is a gzipped archive with a few text files that describe what I've learned, along with C source for a program that parses the binary data for analysis. The code is based on fishstyc's HiMD-Xtract program. Let me know if you find errors or have questions about this (Edited 'cause I couldn't figure out how to attach the file to this post - find it on my website)

I did some research with SS3.2 and a hex editor to see what's different about the way recordings are uploaded. Here's what I found: * If you have previously uploaded a recording with earlier versions of SS, trying to upload it again with SS3.2 will erase it from the disc as with earlier versions. * When uploading recordings with earlier versions of SS, the trkidx??.hma file was modified in the following ways 1) The Source code was changed to 0x5F9E0000 2) Unknown field at locations 0x18-0x1f in the header info structure changed 3) Unknown field at locations 0x4e-0x4f in the header info structure changed from 0x0803 to 0x0044 * In SS3.2, the only thing that changes when uploading now is the source code as in 1) above. There are no changes to other fields in the info structure. Summary: Be careful when trying to upload stuff you may have uploaded with earlier versions of SS. If you use SS3.2 exclusively, you should be safe.

Got a pair of these at my local Target yesterday: Philips Headphones @ Target I'm seriously disappointed in the sound quality. They're louder than my other Philips phones, but they sound kind of muddy - poor high-end response. Makes my MD sound like an old clock-radio and I haven't found an EQ setting that can compensate. Ugh.

Thanks for the advice. Fry's in South Phoenix had 5 for $6.99 ea. Now they have 2.

Basically one of the Sony US marketing dudes giving a 3 minute video spiel introducing the new pro-audio Hi-MD (MZ-M10 & MZ-M100) units at NAMM 05. Describes the two units, some of the capabilities and the SoundForge bundle TBA.