HiMD Transfer for Linux, working

[sfbp]

I went to the command prompt, changed to the folder to where the files were located. I also put in the drmed pcm oma file on the same location and exactly typed the command given by you earlier..I get no result...it just comes back to the command prompt..

I have tried it in both win7x64 and winxp pro 32-bit

If there was an error on the using the ff..commands, I would get the "...not recognized as internal or external command..." from the os..

Wait a second. You typed "ffplay test.oma" but your file named test.oma was PCM, not LP2 - so it ain't going to work.....

What about if you simply type "ffplay"?

[nvee]

my oma file is a pcm recording made on rh1..sometime after this my desktop hardware crashed ( had not converted the pcm omas to wav yet) and I assembled another..of course the omas will not play as we all know..

I saw the 2nd sept post from cbmuser and was trying see if can get it to play and convert..I guess it is still experimental..

even with just typing ffplay..it just comes to the command prompt without any output on screen..tnx for the followup..

[sfbp]

if typing "ffplay" at the command prompt does nothing, then something is seriously wrong. I have no clue what - but this was the way that the original code posted in this thread behaved, for me. The second version, which you should have, didn't do this for me, making me think you may have mixed up the versions.

[nvee]

When I downloaded the version from the link, I deleted the old version before using this version. Either way, I did a double check, removed everything and re-downloaded & extracted from the above link...its the same...

[sfbp]

Maybe the old one is still cached someplace. Such things are possible in a highly-optimized system like W7. Also when you download things, do you extract the files to a directory on C:\ or do you leave them where they are? Maybe there's some problem with paths, and/or old copies in the temporary directory which will get used if you try to run them straight from a downloaded zip folder.

Do you have any "speed-up" software installed?

[cbmuser]

https://rapidshare.com/files/3217379360/ffmpeg-plumbojumbo-970d362.zip - ffmpeg - Windows

https://rapidshare.com/files/910579041/vlc-1.2.0-git-win32.zip - VLC - Windows

https://rapidshare.com/files/790979033/VLC_oma_64bit.app.zip - VLC - MacOS 64-bit

[nvee]

This did the Trick!..the pcm .oma got converted to output.wav and plays without problems..thank you very much...

looking forward to the final version...

https://rapidshare.c...mbo-970d362.zip - ffmpeg - Windows

https://rapidshare.c...0-git-win32.zip - VLC - Windows

https://rapidshare.c...a_64bit.app.zip - VLC - MacOS 64-bit

[cbmuser]

This did the Trick!..the pcm .oma got converted to output.wav and plays without problems..thank you very much...

looking forward to the final version...

Yes, the previous versions were still buggy which resulted in a crash of VLC when opening an .oma file. Also, some DLL files were missing and have now been added.

More updated versions:

https://rapidshare.c...r_mac64_drm.zip - QHiMDTransfer - MacOS 64-bit

https://rapidshare.c...mdcli_mac64.zip - himdcli - MacOS 64-bit (command line version for HiMD transfer)

https://rapidshare.c...mdcli_mac64.zip - netmdcli - MacOS 64-bit (command line transfer utility for NetMD)

https://rapidshare.c...r_mac32_drm.zip - QHiMDTransfer - MacOS 32-bit

https://rapidshare.c...mdcli_mac32.zip - himdcli - MacOS 32-bit (command line version for HiMD transfer)

https://rapidshare.c...mdcli_mac32.zip - netmdcli - MacOS 32-bit (command line transfer utility for NetMD)

https://rapidshare.c...0-git-win32.zip - Updated version of VLC for Windows with integrated decryptor (in case it didn't work for some before on Windows)

The usage of netmdcli and himdcli on MacOS is not straight-forward, please see: http://www.minidiscforum.de/forum/download/file.php?id=1635&mode=view

Adrian

[azanshin]

I Have An MZ-NH600 & 700 but am not able to transfer my mp3 over to the minidisc player.

Am using a macbook C2D 2.13 OS X 10.6, I was wondering do I have to convert these mp3's to atrac,

or does this program transfer it over and then convert the music like sonic stage?

[sfbp]

The problem is not the program - the problem is the unit (NH600/700). Neither has the facility to play MP3 without first conversion to ATRAC.

I am not sure if QHiMDTransfer supports making files on the HiMD, either. Last I heard, it does not.

[azanshin]

So how can I convert the tracks to atrac on mac?

[sfbp]

I don't think you can. Sony never supported Mac with SonicStage.

[azanshin]

Well I converted the tracks to Atrac3plus but still the files will not transfer

[THIS SUCKS]

just checking in again. the true sp download was supposed to be finished last christmas. it has been a whole year past that. can we finally download true sp to standard 80 min disks in normal md mode? thanks...

[cbmuser]

Hey guys,

sorry for not checking back here for a long time! I have had to move from country to country, so you can guess I have been quite busy.

Anyway, there are several good news.

1) The upcoming major official release of VLC contains the universal OMA decryptor which allows to decrypt ALL files encrypted by SonicStage without having to have SonicStage installed or the keys backed up. Very useful for people who had to reinstall their computers and can't play back their content anymore.

Fetch preview versions of VLC here:

Win32: http://nightlies.videolan.org/build/win32/last/

Win64: http://nightlies.videolan.org/build/win64/last/

MacOS (Intel): http://nightlies.videolan.org/build/macosx-intel/?C=M;O=D

MacOS (PPC): http://nightlies.videolan.org/build/macosx/?C=M;O=D

Note: The 2.0 versions for MacOS do not play back these encrypted files at the moment due to a bug which is supposed to be fixed in the release version.

2) The free ATRAC3+ decoder for VLC/ffmpeg is nearly complete and to be expected within the next months. With this decoder, VLC/ffmpeg will also be able to play back ATRAC recordings made with the latest generation of HiMD devices.

3) We will be getting two slots for this years' Google Summer of Code again through VideoLAN. This means, development will gain another boost.

4) HiMD write support has been successfully shown to work for the first time. I was able to transfer an MP3 using "himdcli" on Linux with my MZ-RH10 and it worked! We just need to fix some bugs in this area .

@THIS SUCKS:

NetMD transfers already work, but there is no UI integration due to some bugs yet. Sorry, been busy. But it *does* work! Development will gain another boost during Google Summer of Code 2012. We will have two dedicated students again who will work on the project and get paid. The previous GSoC (2011) already brought major steps forward in the NetMD development (see the progress here: http://www.ohloh.net/p/linux-minidisc).

So, while I would like to apologize for the slow progress, please let me tell you that we are still working on the project and it just takes an incredible amount of time and effort. I understand your frustration, but I can promise you that we are still working and we will get to the point that we will have a full-featured SonicStage replacement, cross-plattform WITH SP downloads. This years' GSoC should bring us there or at least very close to it. I promise!

So, again. Very sorry for the slow pace. But we're still going strong!

Adrian

[cbmuser]

Well I converted the tracks to Atrac3plus but still the files will not transfer

Because the code is still WIP.

Please check this status table regularly, it still says *experimental*: https://wiki.physik....doku.php#status

We just managed to successfully write a MP3 to a HiMD device and play it back: https://lists.fu-ber...y/msg00005.html

This work will be finished after this years' Google Summer of Code, I am currently preparing the task lists for the students who are going to work on it!

Adrian

[THIS SUCKS]

thanks for the reply. i look forward to trying it when its finished

[cbmuser]

Hi,

MacOS X users, please download the release candidates for VLC 2.0 here:

http://download.videolan.org/pub/testing/vlc-2.0.0-rc1/macosx/

These versions support decrypting of encrypted ATRAC-1 and ATRAC-3 files .

For Windows:

http://download.videolan.org/pub/testing/vlc-2.0.0-rc1/win32/

Linux users will have compiled versions of VLC 2.0 available in their favorite distribution soon.

Adrian

[Cool MD User]

This project seems very promising. Thanks to all for your hard work!

I myself have some files that I've been locked out of due to DRM in SonicStage (recordings made back in 2007). I've long deleted the original recordings off the disc and the computer that these files were created on crashed a few months after I made them. I backed up the files, but unfortunately not the DRM keys....these files are in ATRAC3+ 256k, so I'm very much anxiously awaiting the ATRAC3+ VLC decoder!

I even went so far as to call up Sony and beg them to decrypt these files, but they claimed they didn't offer such service and instead pointed me to 3rd-party file converters (which of course don't work if the files aren't playable in the first place). Meh...it's a bit frustrating that they leave their users in the dark like that and it's left up to the open-source community to find a solution...

ETA: I do have one question, regarding this quote:

The upcoming major official release of VLC contains the universal OMA decryptor which allows to decrypt ALL files encrypted by SonicStage without having to have SonicStage installed or the keys backed up. Very useful for people who had to reinstall their computers and can't play back their content anymore.

Do the minidisc players also contain this "universal OMA decryptor"? I've always wondered this. If there was a way to get SonicStage or another program to transfer locked ATRAC files to minidisc, perhaps that could be another way of recovering the recordings? I think I may have figured out a way, but I don't have MD equipment with me currently to test it out...

Edited May 23, 2012 by Cool MD User

[bladze]

"The free ATRAC3+ decoder for VLC/ffmpeg is nearly complete and to be expected within the next months. With this decoder, VLC/ffmpeg will also be able to play back ATRAC recordings made with the latest generation of HiMD devices."

Is this complete now? When ever i try to play my .OMA i get an error saying "VLC does not support the audio or video format "undf". Unfortunately there is no way for you to fix this." Thus, i assume that the ATRAC3+ decoder has not yet been added to VLC?

do you happen to have any idea of when this is due?

Thanks for all the amazing work being done here.

Kind regards,

Ali

[THIS SUCKS]

just checking in. can we download true sp files to net md yet? its going to be awesome!

[toxaco]

just checking in. can we download true sp files to net md yet? its going to be awesome!

Yes that would really make Net MD a quality machine

[Cool MD User]

Hi all,

Just checking in briefly. Any updates on the project? A post back in January said the ATRAC3+ decoder was almost finished, and that it would be worked on/finished this summer. Thanks!

[Cool MD User]

Well...it's unfortunate that this project seems to have stalled, but in the meantime I did some messing around with a hex editor, SonicStage, a minidisc player, and my locked files (ATRAC3Plus, 256K) that I was trying to recover. There were 16 tracks in all. I actually managed to recover them all, for the most part - however, the process was very tedious and I got mixed results throughout the process. Basically, this is what I did:

1) downloaded a HEX editor (xvi32 works well)

2) went to the original computer the files were created on (OS has since been reinstalled, making the files nonplayable by default even on that system)

3) verified that SonicStage would indeed not play the files

4) What I then did was record a dummy track (that is, a track of silence) on my MD recorder that matched the exact format and track length of the song I was trying to recover

5) Imported this track into SS

6) Located the imported .OMA file in the Packages directory.

7) Now, here is where things get interesting. I launched the HEX editor and opened both the imported .OMA file and the original locked .oma file.

8) Once they were both open, I saw a bunch of numbers and letters, basically gibberish. But I was able to locate the track headers - i.e. where the track title, info, format, keys, etc. This is really what took me the most time - figuring out all this stuff.

9) Once I knew where the track headers were located, I went to the locked .oma file, deleted its track header, then REPLACED it with the track header of the file I just imported from the MD. I then saved the resulting file as a new .oma file.

10) I then import this new "hacked" .oma file into SS. If done correctly, SS should still recognize it as a valid .oma file. Now, the funny part: 12 out of the 16 tracks I did this to actually PLAYED at this point!! (Some took several attempts...this was purely a trial & error process and that's why I don't wish to announce it as an "official" solution)

11) For the remaining 4 tracks, SS still did not play them, but (this is key) it saw them as TRANSFERABLE...meaning it can be copied to an MD, unlike the original. My hope here is that I could transfer it over to MD, and if the MD player is equipped with that "universal OMA decoder" mentioned earlier, the files would play on the MD even though SS wouldn't. However, this method only worked on ONE of the files. The other three I could not get either the MD or SS to play, no matter what I did.

12) So, what about the remaining 3 files? None of the above methods worked on them, so I tried recording and importing another track from the MD, this one with a length of only 3 seconds. Performed steps 5-9 again and boom, SS suddenly was capable of playing these files.

I still don't really know how I did it, and thus can't really explain it well...but I guess the message is this: all hope is not lost.

NOTES:

- The recovered files were not perfect. SS had errors converting one of them to WAV format, and it turns out that part of the audio (few seconds) from one track was missing...and another file had random "skips" in it, but otherwise played fine. Definitely better than nothing, though.

- the track headers for PROTECTED and UNPROTECTED .OMA files are DIFFERENT. So, overlaying an UNPROTECTED file's track header on a PROTECTED file will not work. (and vice versa)

- I should note that I used the ORIGINAL computer the locked files were created on (but a re-install of the OS rendered them unplayable). I DON'T KNOW if this method would work on a different computer.

[Azureal]

Very interesting research. I suspect the headers likely contain a length in bytes value for the audio portion of the file, Each header has a specific length as well. Some padding of header length or modification of audio length value in the header may be required to play the full track. A shorter file (3 seconds) would work since playback beyond the end versus playback into invalid data would occur. This is good stuff. I wish I had the time to look in to this further. I would be interested know if you could produce the same result on a different machine.

[Cool MD User]

Unfortunately, now at my place I no longer have a minidisc player. I was at my family's place for the Christmas holiday and that's when I had time to experiment...

I also initially thought that the track headers contained track length info...but I think that may have been debunked after using that 3-second dummy track to revive those other stubborn files (which were ~4-5 min in length; one was 8 min). The dummy tracks of exact length, for some unknown reason, did not work. However, a 2-hr dummy track was used to successfully resurrect one of my locked files, also 2 hours in length.

What the file headers DO contain, I've confirmed, are format (ATRAC3/ATRAC3Plus, bitrate) and, for protected OMA files, the keys needed to decrypt the file. I know this because at first, I tried this exact technique, on a different computer, but my "dummy" tracks were actually ATRAC3 132kbps files, and the locked files were ATRAC3Plus 256K. Nothing I did was working even when I followed the outlined steps above to a T. Now, was this also because I was on a different computer? Unfortunately I no longer have the tools to verify.

I wish I better understood the ATRAC system (or just computer programming in general- this is not my field, so this is all new territory here) so I could give a better explanation, or perhaps delve deeper into this finding...but I guess the reason I undertook this was to get my songs back...and now that I have, I've accomplished my task and deleted everything I had.

[sfbp]

Right. There's only one set of keys for a given install. So you can move .oma files around and they'll still play. Even with Windows mediaplayer and such.

If all your files have headers exactly the same length you may get away with this. But there's no reason a priori why they should.

I think if one wrote a simple utility to copy data into a known header, then the only difficult bit is convincing something to rewrite the audio data back into the file. After that, no encryption. That's what the File Conversion Tool (FCT) does. The only question is whether the FCT insists on the data matching the install. If not, its possible someone might patch the FCT to ignore.

[THIS SUCKS]

just checking back in. can we transfer true sp to the units yet? thanks. its been a long wait....

[Cool MD User]

If all your files have headers exactly the same length you may get away with this. But there's no reason a priori why they should.

Actually, now that I think about it, the headers of the files I played around with WERE the same exact length. I can't remember whether protected and unprotected OMA files had different-length track headers, but the protected files certainly had more "code" in the header (again, most likely encryption keys, etc.)

[sfbp]

If tracks have names with same number of characters (and other metadata such as artist, album, date/time) then it will work. Requires a fair amount of discipline to do reliably. But possible.

[Balrog]

Where can I find a Mac version for this? I'm looking for something to work with OS X 10.9

[adamski777]

i know this is probably a dead thread now, but is the current build of QHiMDTransfer from 17 December 2016 allowing true SP downloads to devices - or do we still need to use the python script downloadhack.py?

[cbmuser]

15 minutes ago, adamski777 said:

i know this is probably a dead thread now, but is the current build of QHiMDTransfer from 17 December 2016 allowing true SP downloads to devices - or do we still need to use the python script downloadhack.py?

You should post these questions to the mailing list here: https://lists.fu-berlin.de/listinfo/linux-minidisc#subscribe

As for SP downloads, it should be possible to perform these downloads using "netmdcli" which is available on MacOS and Linux.

Don't know whether we currently have Windows builds for the CLI utilities.

Adrian

[sfbp]

Really? You can go in both directions, to and from the PC?