[WIP] Adding audio mode to initiator mode

[andrewocyeah]

This is a work in progress to add audio mode to the
Initiator mode of the bluescsi in order to read audio DAT tapes on a DDS drive.

This addresses this issue: #131

[erichelgeson]

Hi @andrewocyeah - just following up as this is marked WIP - anything we can help test? What is left? Thanks for the contribution!

[andrewocyeah]

Hi @erichelgeson !,
First of all this code works, but has some issues that need to be ironed out,
To use this code add 'AudioMode=1' into the bluescsi.ini file

There are many misc read errors that occur, almost all of them are fixed via restarting the BLUESCSI, or ocaisionally the attached device.

Audio mode data uses interpolation flags, that act as a checksum. My code is able to record these and will raise g_initiator_transfer.all_ok = false; when it finds one. The error that occurs is rewinding the device is very difficult as it seems many commands to do this, are not implemented.

The data mode code (what currently exists) is capable of reading multiple sectors of data at a time. In Audio mode (this pull request) despite continuous debugging I can only read 1 sector of data at a time.

I am yet to be able to read the capacity of the attached device, so I set the sector count to be very very big, and the device will reach the end of data, but try to keep recording, (the data IS on the SD card so it works regardless but is VERY ugly)

Also I only tested this code with 1 SCSI DDS3 tape reader, so I expect things to fall apart if I use a different one.

Feedback welcome!

[dericed]

I just did some testing on this PR with my SDT-9000 (firmware 12.2). This drive and firmware combination supports AUDIO MODE.

I set bluescsi.ini to

[SCSI]
Debug=1
InitiatorMode=1
AudioMode=1

I then started a video of this process with a split-screen of the DDS drive & BlueSCSI with the console log at https://ia904607.us.archive.org/25/items/datstrue-read/bluescsi_audiomode_test_20240820.mp4.

Here's some notes on that video:
00:00 - I start recording, power up the DDS drive and insert the tape. The DDS drive always does a bit of a shuttle of the inserted tape.
00:42 - I powered up the bluescsi
00:51 - The log says that Audio Mode is set and the log then continuously gives a "Blank Check, Code: Cannot read medium, unknown format" error
01:01 - I then unpower the BlueSCSI
01:07 - I power the BlueSCSI back on.
01:28 - The DDS drive is found, set to audio mode, and start transferring data. The log line in this PR shows the sector (aka 'frame' in DAT audio tapes), the spped, and a tally of the error flag on the left, right, and both channels of each audio frame transferred.
02:47 - I was curious so I pressed the eject button on the drive and then the log shows "Logical unit not ready, cause not reportable" and then "Medium not present" which makes sense since I hit eject.
03:01 - I insert the tape back in, so the log switches to "Logical unit not ready, in process of becoming ready".
03:11 - Eventually I shows "Not ready to ready transition, medium may have changed"
03:12 - The data transfer continues, perhaps a gap or overlap with where it left off.
04:00 - I stopped the transfer by unpowering the BlueSCSI.

I put the resulting files in https://archive.org/download/datstrue-read/20240820_bluescsi_audiomode_test/ and a copy of the log at https://gist.github.com/dericed/821e9099ce32bb54cedc588eeddc7793.

Some comments:

• Sometimes the initial detection doesn't work and I need to restart the BlueSCSI. For instance at 00:51 I get "Blank Check, Code: Cannot read medium, unknown format" errors but this is overcome by power cycling the BlueSCSI.
• The tape doesn't move continuously during transfer. I see the tape rolling along, stop, back up, stop, then play again. The process isn't re-reading frames with errors, but I'm confused why the tape moves in this shuffling pattern while the log continuosly shows data being transferred.
• The log hardcodes a sector count of 1000000, so I understand that the progress counter is a bit inaccurate. Perhaps this can be removed and there can just be a sector tally.
• The resulting data stream looks good, as intended, and the audio and metadata can be parsed apart well.

[erichelgeson]

I think this is when the audio mode is not set or fails to set, the drive expects audio format and when it sees the data format replies BLANK.

The tape doesn't continually move for DATXtract either - I believe it fills the buffer as if you do one read it moves, wait till the tape stops, do another 20 reads and the tape doesnt move.

We should probably log out time stamps instead of a counter - I haven't found a way to read the length of a recording without seeking the entire tape, which doesnt seem useful.

Retries need to be looked at. Audio processing could be moved out of the pico or disabled with a flag if someone wishes to have the raw data. I'm not the target consumer so I don't know how people would use this.

I've not found a way to read faster than 1x in the docs. Nor has the docs on the "Fixed block read" worked as described in the scsi/sony specs.

Great work, this is really close!

[dericed]

Hey @erichelgeson @andrewocyeah, I was looking at this commit and see that this SCSI log line is changed. In the new version it is specific to the details of audio_mode tape transfers. I suggest this should be a conditional, so if audio_mode then use the new log line, else stay with the original.