Add audio mode to initiator for DAT tape drives#321
Add audio mode to initiator for DAT tape drives#321erichelgeson wants to merge 1 commit intomainfrom
Conversation
Adds sequential device (tape drive) support to initiator mode, enabling audio DAT tape reading on DDS drives. Includes SCSI tape commands (rewind, locate, read position, mode select/sense), audio frame metadata tracking, and interpolation error detection. Based on #157
erichelgeson
force-pushed
the
initiator-audio
branch
from
4465436 to
e8f82eb
Compare
| uint32_t interpolation_both; | ||
| uint32_t good_frames; | ||
| uint32_t all_frames; | ||
| uint8_t null_frames; |
There was a problem hiding this comment.
null frames max set via config is 300 - over the 255 max of a uint8_t
|
|
||
| uint32_t position; | ||
| scsiReadPosition(&position, g_initiator_state.target_id); | ||
| logmsg("Starting position: ", (int)position); |
There was a problem hiding this comment.
I'm not sure but we log the start position then immediately rewind - is that intended?
|
My compaq branded sdt9000 has come alive and going at it in audio mode seemingly as it would normally be expected. I gave up on a 120 min tape taking too long, so using a 60 min tape instead. If going by the reporting on serial, looking at the count of frames and timecode, the drive is reading and writing slower than real time playback. edit - I had debug enabled, will try another test without it to check. edit again - it was still slower than real time. Weirdly In the initial test with a 120min tape, when manually stopped after 62 minutes and ejected, I noted the tape had barely transported even a quarter through the reel... The resulting output on sd card is now a .img file 60 min tape reached reported null frames before 54 mins and continued through to the end of tape
|
|
The resulting .img file - I am assuming this is currently defined for output as the tape drive and audio is an unknown format. The log reports Type = Not Supported, trying direct access Is this how the output was intended and will always be, or could a new type be written in to define raw, if not convenient processing to wav ? Most cases users I presume will want a wav output, some advanced may still want this raw data. edit - thinking of raw audio and looking up a bit, I threw the img file into a couple of audio packages. The audio from the test tapes is indeed in there! But without a header for the file, the byte order or whatever else is unclear and would need to be defined for clean audio. There is loads of noise on a basic raw import. Again my understanding and persistence to try ends there. This is quite the development though, the code is now indeed functionally working alongside the updated main. At least with Sony SDT9000 drives @dericed Your previous uploaded test output files, did you have any further success interpreting the raw data correctly? I tried a few of them importing as raw audio again and found the same issue of noise, also your mp3 etc with that baked in |
|
Tried the usb bridge mode in windows - not expecting a thing... but there was a thing. Windows behaved strangely unreliable. As well as Pico 2, "Bluescsidevice" appeared for a while and a constant unstable popup alerting to put media into drive X... but only when a tape is inserted. I would presume because the drive is not switched into audio mode that the dat tape is not recognised. I don't have any dds tapes with data on to otherwise have seen the difference in behaviour. does that suggest a connection is somewhat going through? In time is there any viability technically to enable this function for tape drives and audio mode |
|
There's nothing in this PR related to USB MSC - that is only for mass storage devices, eg HDD/removable media. Someone could write an app to send raw scsi commands over usb to tapes, but that's outside the scope of this PR. |
|
I've since now discovered read_dat and compiled the decoder part to run on mac. It does exactly what I was envisaging and can be used with the raw file (without the tape drive code that runs normally before it). It interprets the audio data from the non audio data and removes invalid frames, automatically processing tracks into header written wav files. And so for reading audio DAT tapes in capable drives (SDT9000 at least), I affectively call this code here now functional as would be expected. But the raw data needs high level decoding with a tool such as read_dat. Could any of read_dat code be implemented in some form to auto process the raw data output and leave wav on the SD card as part of the function? I've got to clean my drive and run more tests to be properly certain of full output - my tapes were stored poorly by their owner and have dropout glitches which I want to be sure is the tape over the drive and bluescsi operation. |
|
Hi @archivistocrat, there's an ffmpeg patch at https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/message/FCGZCROZHDVCP77AWETVKQWGP2VEAZKQ/ that can demux the datastream read from DAT tape (there you can use |
|
Great stuff thanks for info and linking those. Haven't been able to patch ffmpeg and compile a build but did patch the read_dat code with improvements said to have been brought over from that work..? From my testing, a good known tape transfers on this PR/branch perfectly, just slower than realtime. Then work to decode the raw data with the tools mentioned once compiled/patched. Just still the initial errors having to recycle the power a few times to get it going. Went into the drive and removed the tired and black auto-cleaning brush before a full cleanup. The problem tapes still had the same dropouts. I have now gone to buy the cables and the LSI card for testing problematic tapes with the old apps for error correction, which will decide whether to continue bothering or not. It was fun to link the hdd led in my old IDE enclosure into the bluescsi and cut a hole out back for the SD card, have now cut +line in an old usb cable for serial data only. However I'll now have to cut another hole in back and wire in a 68HD connector for the software/PCI card use. |
4 participants
Adds sequential device (tape drive) support to initiator mode, enabling audio DAT tape reading on DDS drives. Includes SCSI tape commands (rewind, locate, read position, mode select/sense), audio frame metadata tracking, and interpolation error detection.
Based on #157