Much technobabble ahead. Read at your own peril.
OK, ATRAC is lossy and frequency-based. You cannot feed it linear data and
expect it to come back exactly as it was before. It divides an input sample
into 512 spectral elements, which are themselves grouped into 52
nonuniformly distributed bands. Frequencies within the same band are
considered maskable by the center frequency of that band.
If you really really really want to record data through ATRAC: Pick a
sequence of frequencies, and consider them "bytes" or "words." Pick them far
enough away from each other (in frequency) so that they cannot mask each
other. I.e., pick frequencies that all lie in separate bands. Also, each
word must be some multiple of the ATRAC block size in length: 11.6ms (long
block, 512 samples), or 2.9ms (short block, 128 samples). If you use one
frequency from each band, you can encode 52 words per block. The ATRAC bit
allocator only has enough bits to encode on average 3.4 bits per sample. The
"bit size" of your words is translated to amplitude of the chosen
frequencies. Assuming a short block, that means you have 3.4 bits/sample *
128 samples = 435.2 bits per block to work with. 435.2 / 52 words gives 8.37
bits per word. You can set the amplitude of each word within a ~8 bit
dynamic range, let's say exactly 8 bits for convenience.
So, to encode 52 bytes of data, select 52 frequencies and set their
amplitude according to the byte value. Take these 52 sine waves and sum them
together into a 2.9ms chunk.
You need to select the amplitude range carefully, to prevent overflow. With
52 waves being added, you need 6 bits of headroom, so your sine waves'
amplitude should range from 3-10 bits in value. Continue generating these
2.9ms chunks for each successive 52 byte block of input data.
Of course, what you're doing here is *expanding* your input data by a factor
of 5 so that it can feed thru ATRAC's 5:1 compression unmolested. You will
be able to store 140MB of raw data in 75 minutes, not exactly a wonderful
data transfer rate. Comparable to old streaming tape drives. I suppose if
you only want to use MDs for archival backup, that's tolerable...
Oh: decoding the data now requires you to essentially recreate ATRAC's own
encoding step: you want to run an FFT or MDCT over the audio data to split
it into frequency bands, and derive the energy of each frequency band of
interest, which becomes your original data byte.
The integrity of the transfer depends on the MD's ATRAC encoder using the
same 2.9ms frame boundaries that you used. I'm not sure how to guarantee
this, other than insuring that your computer's S/PDIF output is completely
idle when you're not streaming data to it. You'll also probably need to
generate a 2 second preamble, and use Synchro Record on the MD deck, to give
it a chance to lock into the digital signal and start recording. You may
need to include a dither signal to keep the digital signal valid during runs
of zeroes and such. Best bet is to gzip your input data first, which will
pretty much guarantee that you're feeding non-zero data into the system.
So: if anyone still feels like using their audio MD deck for computer data
storage, there you go. Have fun.
(The ravings of someone who has spent 20 of the past 36 hours reading Sony
patents...)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
-----------------------------------------------------------------
To stop getting this list send a message containing just the word
"unsubscribe" to [EMAIL PROTECTED]
