wolb1 Posted May 4, 2020 Report Share Posted May 4, 2020 Ich habe beobachtet, dass alle oma Dateien, die mit dem Walkman MZ-RH1 als verschlüsselte atrac3plus oma Dateien auf den PC übertragen wurden, von ffmpeg entschlüsselt werden können. Das gilt sowohl für normale MD (atrac3) als auch für HiMD (atrac3plus, 256 kbps). Aber HiMD Dateien von anderen Walkmen (z.B. MZ- NH1) können zwar auf SonicStage übertragen und dort abgespielt werden, aber nicht mit ffmpeg Decoder entschlüsselt werden. Ich schließe daraus, dass die ffmpeg Programmierer nur die Verschlüsselungs-Software geknackt haben, die im RH1 eingebaut ist, aber nicht die Software von OpenMG. Immerhin ist auch das schon ein großer Schritt, der bestimmt viele Jahre an Arbeit gekostet hat, um die verdammte und wertlose Digital Rights Management (DRM) Philosophie von Sony ad absurdum zu führen. Sony stellt zwar ein "File Conversion Tool" zur Entschlüsselung zur Verfügung, wenn man aber vergessen hat, dieses laufen zu lassen, sind nach einem System Crash mit System Neuinstallation, was bekanntlich bei Windows sehr oft passiert, alle oma Dateien unbrauchbar. Das gilt sogar für PCM Dateien, die als verschlüsselte oma Dateien gespeichert werden, mit der gleichen Dateigröße wie eine WAV, die aber nicht mit einem normalen Player abspielbar sind. Übersetzung: I have observed that all oma files transferred to the PC with the Walkman MZ-RH1 as encrypted atrac3plus oma files can be decrypted by ffmpeg. This applies to both normal MD (atrac3) and HiMD (atrac3plus, 256 kbps). But HiMD files from other Walkmen (e.g. MZ- NH1) can be transferred to SonicStage and played there, but cannot be decrypted with ffmpeg decoder. I conclude that the ffmpeg programmers only cracked the encryption software built into the RH1, but not the software of OpenMG. After all, this is also a big step, which has certainly taken many years of work to lead sony's damned and worthless Digital Rights Management (DRM) philosophy ad absurdum. Sony provides a "File Conversion Tool" for decryption, but if you forgot to run it, after a system crash with system re-installation, which as you know happens very often in Windows, all oma files are unusable. This even applies to PCM files that are stored as encrypted oma files, with the same file size as a WAV, but are not playable with a normal player. Quote Link to comment Share on other sites More sharing options...
sfbp Posted May 4, 2020 Report Share Posted May 4, 2020 .... and why would you want 16-bit PCM when ATRAC is so much better format, being logarithmic instead of linear? Please ignore all the diehards who tell you that it's lossy (true but insignificant). PCM only seems viable to me when you have 24 bits at least, which gives you a lot more headroom than 16 bits. Another way of saying, for real recordings, it's the bit-ness which really matters. They *did* crack it. I'm not sure why the "bypass" only works for RH1, not something I have ever noticed. Thanks for pointing it out - something I will be checking in the next little while. My recollection was that getting the code to read ATRAC CDs (which have nothing whatsoever to connect them to the RH1) was a trivial modification. Maybe that's because they are made by Sonic Stage and it knows to strip out the leaf ID of whatever unit was coded into the files when recording. The other limitation is that I don't think ffmpeg handles all rates properly! For example there is an MDLP3 (105kbps) which is largely undocumented. Always use FCT!! Kind regards Stephen Quote Link to comment Share on other sites More sharing options...
wolb1 Posted May 4, 2020 Author Report Share Posted May 4, 2020 Dear Stephen, thanks for your reply. FCT = file conversion tool. I used PCM also believing that it would be better. Thank you for your explanation. I am not quite sure whether my files that could not be decoded where uploaded by which walkman. These files where rather old and FFmpeg did show: [oma @ 00000000001ce040] File is encrypted [oma @ 00000000001ce040] No encryption header found C:\ProgramData\SonicStage\Packages\Hi-MD 2019-07-14 18_10_12\010-2019-07-14 18_10_12.oma: Operation not permitted That is atrac3plus, 256 kbps BTW, is there a bit depth value in oma files? Kind regards, Wolf Quote Link to comment Share on other sites More sharing options...
sfbp Posted May 4, 2020 Report Share Posted May 4, 2020 Ok. I tested it. Here's the deal: when you record something and send that file TO the computer, the resulting upload IS encrypted. But FFMPEG can read it. I just checked, by making a microphone recording on the MZ-NH1. Now it IS possible that firmware and Sonic Stage have both been updated since your files were made, removing the restriction you discovered. I'm not really sure. HOWEVER: if you send encrypted music FROM the computer (TO the MZ-NH1) the resulting disk is not readable in another computer (by connecting the NH1 to a different PC). Remember that a change in Windows can make it seem like a different computer. So what may have happened is these "old files" of yours were recordings that started on the PC, and got encrypted before sending to the NH1. If they were encrypted with a Leaf ID of 0 (such as if the FCT had been run) instead of a Leaf ID tied to the current installation of Windows, then they can be read elsewhere. But if not, those files are useless, even if you to copy them to another PC. Remember that because all files on HiMD are visible to the Windows file system, they felt they HAD to encrypt them in order to stop people copying them WITH WINDOWS EXPLORER. This doesn't happen on SP/MDLP legacy disks, which is a whole different ball game. Your files are encrypted doubly - first with the ID of the device, second with the ID of the PC. If they are transferable to the MZ-NH1, they should play. But it may be that you cannot even transfer them. If this explanation turns out to be rubbish (I'm perfectly capable of writing rubbish), then there must have been a relaxation by later firmware/software. I hadn't run into this for a while but I think you will agree the architecture is consistent with what they tried to do (no point in arguing that they should not - they did it). You can try to see if you can decrypt these files with FCT. If you can, then all is well and you can move them about wherever you want, including sending them to a disk, and then getting the music off that disk onto another PC. What it really means is that you MUST do the decryption as soon as you upload. If they PLAY in SonicStage then just be happy and export them to WAV file and forget about the oma for now. Oma is a 32-bit format. 8-bit exponent (logarithm), 24-bit mantissa (significand). Quote Link to comment Share on other sites More sharing options...
wolb1 Posted May 5, 2020 Author Report Share Posted May 5, 2020 Dear Stephen, thank you for your extensive help. Yes, the files had been uploaded to Windows 10 from Walkman, that crashed and has been installed new on another partition. But I had a backup of all files in RAR format and could restore them. But I did not have a backup of the SSprogram and all the OpenMG .dat files, don't know whether this would help? Now there are three types of files: 1. Files not encrypted 2. Files encrypted but can be played in FFmpeg 3. Files encrypted but cannot be played in FFmpeg. These files cannot also be converted by FCT: error messages. I wonder why FFmpeg can play and convert some and others not. Kind regards, Wolf Quote Link to comment Share on other sites More sharing options...
sfbp Posted May 5, 2020 Report Share Posted May 5, 2020 Pretty much as I outlined. Still not sure whether something changed at the MD end. But I think once you've sent an already-encrypted file to the MD disk, it is not transportable. Do the files causing you grief play in Sonic Stage? If so then 1. you can play them back and record the result (a pain, but if they're important.....) 2. you can export them to WAV. The only backup that appears to be really useful, as far as encrypted files goes, is a SS backup. When THAT gets restored, there's some clever stuff the program does where it hooks up with the Sony server (which was still running the last time this issue got discussed - but we never are quite sure about it) and magically the files get their validity back again. I agree that it would be nice for ffmpeg and the MD libraries to do the same, but no one can explain to me what exactly that process consists of. So a lot of research needed, for not much gain. Quote Link to comment Share on other sites More sharing options...
wolb1 Posted May 6, 2020 Author Report Share Posted May 6, 2020 No, I did not use SS backup as it deletes stored files without notice. Yes, research would be helpful. An important researcher has been Adrian Glaubitz, Berlin, Germany with 5 other programmers, but he is offline, I suppose. https://wiki.physik.fu-berlin.de/linux-minidisc It seems that Sony MD technology has been superseded by mp3 and is already something like vintage. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.