d-9 Posted October 19, 2020 Report Share Posted October 19, 2020 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 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.