Pavlos (pavlos) wrote,

  • Mood:

Musical Hard Drive 1 - Geeks 0

cairmen came over the other day with an IDE hard drive from a Tascam 788 digital portastudio, which contained some voice recordings that Strange Company would really like to extract to finish the soundtrack for their upcoming movie. The Tascam 788 is sort of a 24-track pro-quality recording iPod (it is a multitrack recording deck that records to its own internal hard drive).

The orthodox method of exporting the recordings is either analogue (I guess that would work but is sort of admitting defeat) or buying a proprietary Tascam CD recorder which then records standard WAV audio. We were hoping to avoid these options by reading the data directly from the hard drive. Despite applying some mid-level geek skills (I'd say about level 5) we did not succeed. Here's where we got to:

As expected, we were able to attach the hard drive to my Linux PC and read it as a big binary chunk. We know it's not scrambled because we could easily find track names and other ASCII strings in the data. There's no indication that the data is somehow "copy protected".

We were not able to recognise the type of file system of the drive. We tried the usual DOS and Linux formats, as well as QNX4, BeOS, and a few others. Linux wasn't able to recognise the partition table at boot time, nor mount the filesystem with the -t option. Admittedly it was a 2.4.x kernel, so BeOS support was described as experimental. We didn't try a 2.6.x kernel yet, which might support more filesystems (yes, we did actually compile the above filesystem support into the kernel, run LILO, reboot, etc.).

A web search on press releases indicates that Tascam adopted BeOS after producing the 788, and the manual describes the internal disk format as "Tascam original format". That probably means "arse".

We did pipe various randomly chosen chunks of data to the sound card, and (as expected) most of it was silence, but we did hit some very large blobs (tens of MB) which came out as almost white noise. There was some faint pattern there. We tried byte swapping and we did verify that WAV audio thrown directly at the sound card plays as expected. So we surmise that if the data was audio (what else could it be?) it wasn't in a raw 16-bit format. Differently L/R interleaved or high sample rate audio would have sounded more recognisable.

It may be 24-bit audio and/or losslessly compressed audio, both of which are features of the machine. Uncompressed 24-bit audio ought to be fairly easy to unmangle with a small C program, or some cunning invocation of "dd". There are only about 9 sensible ways of throwing out 2/6 bytes in the stream. Compressed audio would probably be a lost cause if we don't have a reliable start of the stream, and the files are non-contiguous.

So there.

  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.