d-9

@cybercase That would be great if you can port it to web-minidisc, I was thinking about doing that one day if I got really bored! The netmd_test is a rough python proof of concept I threw together to easily check that adding handshakes and re-reads did not break compatibility with a bunch of devices, my fork of linux-minidisc has updated libnetmd & netmdcli: https://github.com/deenine/linux-minidisc Proably the easiest way to see the diff is to look at this PR: https://github.com/gavinbenda/linux-minidisc/pull/3/files Please note I was slightly naughty and fixed a few other issues in linux-minidisc while I was at it, but you should easily see the 780/980 related fixes: 1. Modification to read functions, so that if the netmd device returns 'status_interim', it re-reads to get the actual response. 2. Addition of 'handshakes' to a number of the functions, so that they work with the netmd deck. Happy to take the discussion to github

@NGY do you still have this?

Platinum-md uses the linux-minidisc netmdcli binaries, so I have put in a pr to the fork of linux-minidisc that pmd uses...but as it happens I have also put a pull request into pmd for the rh1 upload function, that happens to include the osx 780 functionality because I had to tweak a few bits of linux-minidisc for that: https://github.com/gavinbenda/platinum-md/pull/62 Unfortunately I don't have a Linux or Windows build system, so cannot update the other binaries, but gavin will take a look at some point

Excellent! Glad it worked for you? What platform did you build it on?

thanks for testing that again @blixabloxa you had me worried for a minute! I have updated the first post in this thread as I have worked out other parts, I sorted the disc titling and other issues. There is a proof of concept version here, I have tested this with the n10 and je780 and it *appears* to work, will do some further testing and then see about getting an updated release for platinum-md: https://github.com/deenine/linux-minidisc

Thanks for testing @blixabloxa was that with a blank disc in the rh10?

This is talking about the windows environment variable PATH, which is a list of places to look for executables. It sounds like you've got it sorted, but here is an article on how to set them if you ever need to in future https://www.architectryan.com/2018/08/31/how-to-change-environment-variables-on-windows-10/ I'll update the readme to clarify this.

That's great, thankyou for testing.

Thats fantastic, thankyou for testing and posting the details. I have added the device ID for the S500, so please pull down the latest version and try again with the S500: git remote update git pull

@EnderIII I have done a bunch of tweaks to the code to make it work with python27 on windows, without needing to install extra libraries (I think). Please do the following to update to the latest version git remote update git pull

Easiest way to test python is just 'python'. Then exit() to return you to the terminal.

Thanks for taking a look, I had forgotten that there isn't a python2 alias on Windows, I'll update the readme. Have you done the step of copying the libusb dll into the same directory as python? "If you are using 64-bit Windows, copy libusb-1.0.dll from the directory where the tool was cloned, to the python2 install directory (e.g. C:\Python27), or if you are using 32-bit Windows copy libusb-1.0-32.dll instead and rename it to libusb-1.0.dll" edit: another thought, is platinum-md installed and working? If this is a windows machine where you use sonicstage, you will need to do the zadig driver replacement step for each device, then roll it back to the sonicstage driver if you want to use sonicstage with it again: "You will need to use Zadig to install the WinUSB Driver. Connect your NetMD device, open the app and click the "Install Driver" button. Please note, this will disable Sonic Stage from having access to the device, you'll need to run Zadig and 'reinstall' the old driver to use it again. https://zadig.akeo.ie/ " The reason for the lack of output is I tried to be too smart with the netmd error handling, and didn't test with other errors, I'll push an update so it gives some output

If your on a mac, it should be super easy to run the test script, Windows is a lot more hassle :( I haven't noticed any slowdown on the n10 when running with the handshakes, but I don't know if there are older/slower portables out there? The rh1 is noticible MUCH faster, I am guessing it's usb 2.0 not usb 1.0. It will be fairly trivial to do some performance testing to see if this makes a difference

So far, I have found no ill effects of using the handshakes for devices that do not require it - I have tested on my N10, my RH1 and a friends N10 - but I would like this to be tested on a wider range of devices/generations. So if anyone has a netmd portable and knows how to use github/python, please run the test tool and create an issue in the test tool repo with the type of device and the results! https://github.com/deenine/netmd_test/blob/main/README.md

I have done some research on the JE780 (which probably also applies to the JB980):

I have taken a look at why the MDS-JE780 does not work with the linux-minidisc libraries (either C or python) used in Platinum-MD or the TS port used in web-minidisc. I believe that the issues I have found here also explain why these tools do not work with the JB980, NT1, or the various netmd bookshelf systems, but so far I have only tested with the JE780 and a LAM-Z03. This testing was done by capturing traffic between my JE780 and Sonicstage on windows 10-64, and comparing to the information in the linux-minidisc documentation, source and with a packet capture of the same sonicstage commands run against my N10. Traffic was captured using USBPcap (https://desowin.org/usbpcap/) running on a windows 10 laptop, and then inspected using wireshark. Packet captures for the n10 and je780 are attached. There are two significant differences in the netmd protocol as implemented by linux-minidisc on the majority of portable devices, and as implemented by the je780: 1. The JE780 responds with status '0x0f: interim response' to most commands, requiring a second read from the device to complete the command. 2. Many commands require a handshake command to be sent in advance, to enable the command. The NetMD libaries specify a variety of responses, such as '0x09: Accepted', '0x0a: Rejected', which the netmd prepends on all response messages. A typical message flow for a portable device, such as the n10: out -> 0x00 0x18 <message> in <- 0x09 0x18 <response> The 0x09 byte at the start of the response from the device indicates the command was accepted. A typical message flow from the JE780: out -> 0x00 0x18 <message> in <- 0x0f 0x18 <message> in <- 0x09 0x18 <response> The 0x0f byte at the start of the first response indicates that this is an interim response and a second response will be available. In most cases the interim response body is the same as the outbound message. On re-reading from the device, an 0x09 byte is supplied, with the normal response. Adding a re-read from the device, in the event of an interim response status, enables some functionality with the JE780, however a number of commands require a 'handshake' to be completed in advance, otherwise the re-read of the command will respond with 0x0a: Rejected. For example: 255 out -> 00 18 09 80 01 02 30 88 00 00 30 88 04 00 ff 00 00 00 00 00 (Get Player Status) 262 in <- 0f 18 09 80 01 02 30 88 00 00 30 88 04 00 ff 00 00 00 00 00 (0x0f Interim response) 268 in <- 0a 18 09 80 01 02 30 88 00 00 30 88 04 00 ff 00 00 00 00 00 (0x0a Rejected) Get player status fails, with 0a. 271 out -> 00 18 08 80 00 01 00 278 in -< 09 18 08 80 00 01 00 Handshake accepted 281 out -> 00 18 09 80 01 02 30 88 00 00 30 88 04 00 ff 00 00 00 00 00 (Get Player Status) 288 in <- 0f 18 09 80 01 02 30 88 00 00 30 88 04 00 ff 00 00 00 00 00 (0x0f Interim response) 294 in <- 09 18 09 80 01 02 30 88 00 00 30 88 04 00 10 00 00 09 00 00 00 07 88 04 00 03 40 ff 40 (09 Accepted) Following the handshake, the command the failed previously is successful. Of the commands I have tested so far, I have found the following: No handshake required: - Get disc flags - getDiscTitle Requires 18 08 80 00 01 00 handshake: - Get Status - getOperatingStatus() Requires 18 08 10 10 00 01 00 handshake - Get Capacity Requires 18 08 10 10 01 01 00 handshake: - get track count - getTrackLength Requires 18 08 10 10 01 00 00 handshake: - moveTrack Requires 18 08 10 18 01 00 00 handshake:: - syncToc Requires 18 08 10 18 02 01 00, 18 08 10 18 02 00 00, 18 08 10 18 02 03 00 handshakes: - set track title Requires 0x00, 0x18, 0x08, 0x10, 0x18, 0x01, 0x00, 0x00 handshake: - write disk header Requires 18 08 10 18 01 01 00; 18 08 10 18 01 00 00, 18 08 10 18 01 03 00 handshakes: set disc title then requires 18 08 10 18 01 00 00 to write title, otherwise just clears title. All work without handshake, but all return status interim and require re-read. - Play/pause/stop/goto track - get track encoding - getTrackFlags - enterSecureSession - eraseDisc - eraseTrack - rename Group - delete Group Works without re-read or handshake. - Get position - Leave secure session - getLeafID - syncTOC Set disc title does not currently work. Command is accepted with triple handshake, but it clears disc title rather than setting it. So far I have modified the python libnetmd.py and created a test script, which I have successfully run against my 780, n10 and RH1, and I have had run against a LAM-Z03. If you have access to a netmd bookshelf system, a JB980 or a NT1, it would be very interesting to see the results of running the test script, to confirm that the same approach works against other devices. The test script is here, with instructions to run in the readme: https://github.com/deenine/netmd_test Unfortunately this requires python2 and is not compatible with python3, I have begun porting it, but ran out of time to focus on this. I have also hacked a copy of the linux-minidisk libraries to do the re-read on interim, to test the transfer of music to the JE780. This throws some error messages, but successfully allows transfer of music to the deck: $ ./netmdcli -v send Test.wav netmd_init opening netmd getting dev_name Sony MDS-JE780 audio file size : 37535822 bytes supported audio file detected data chunk position at 70 audio data size read from file : 37535744 bytes audio data size calculated from file size: 37535744 bytes netmd_acquire_dev: Unknown Error netmd_secure_leave_session : Unknown Error netmd_secure_set_track_protection : No error netmd_secure_enter_session : No error netmd_secure_send_key_data : No error netmd_secure_session_key_exchange : No error netmd_secure_setup_download : No error generating packet 1 : 1048552 bytes ... generating packet 35 : 1048576 bytes last packet: packet_data_length=835608 + frame_padding=0 = chunksize=835608 generating packet 36 : 835608 bytes netmd_prepare_packets : No error total transfer size : 37535768 bytes, 18328 frames of 2048 bytes 1048576 of 37535768 bytes (2%) transferred (1048576 of 1048576 bytes in packet) ... 37535768 of 37535768 bytes (100%) transferred (835608 of 835608 bytes in packet) netmd_transfer_song_packets : transfer took 107 seconds (342 kB/sec) netmd_secure_send_track : No error New Track: 0 netmd_secure_commit_track : No error netmd_secure_session_key_forget : No error netmd_secure_leave_session : No error netmd_release_dev : Unknown Error After hacking the linux-mindisc libraries to work with the 780, testing shows it spends a lot of time in the netmd_poll sleep state, compared to my N10, with the original sleep time of 1s, this lead the netmdcli print disc info (just the bare netmdcli command with no parameters) to take ~50s. Tweaking the sleep time down to 5ms dropped this to 0.54s, but at this point it was failing to send tracks successfully due to hitting the timeout limit. I have set it so the timeout increases as it goes around the loop, which means sending tracks works, but other operations are still fast. Going forwards, there are three steps: 1. Fix the issues around naming tracks/discs, work out missing handshakes, etc, so all relevant functionality works with the JE780. 2. Test against further devices - to confirm that the bookshelf systems and others use the same handshakes as the JE780, and it needs to be tested against a range of the portables that currently work with linux-minidisc - so far the presence of the handshakes does not appear to impact operation at all, but if it is shown to impact, then more complex logic will need to be added to only handshake when required. 3. Patch linux-minidisc C and the web-md TS library, so platinum-minidisc and webmd are compatible with the new devices. 780.pcap n10.pcap