Re: [linux-audio-dev] Reverse-engineering files

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Reverse-engineering files
From: Jay Ts (jay_AT_toltec.metran.cx)
Date: Fri Dec 01 2000 - 02:55:36 EET


Paul W wrote:
>
> Me too. I'm surprised at the current state of samplers on the market.
> AFAIK *every* sampler currently sold takes only SIMM memory, which is
> hard to find except used, and it's overpriced.

Yep. E-mu's products need to use expensive memory for the sound ROMs,
which needs to be custom-manufactured for them. But what I think
strange is that their new line of Proteus family synth modules do
not also include some standard RAM SIMM/DIMM slots, plus a quick
(USB/ethernet) interface to the computer for downloading additional
sounds.

> Likewise I'm amazed how many samplers come with floppy drives
> considering that internal Zip drives now retail for what, $100 or
> less?

That, I can sort of understand, because synths are different than
PC computers. Synths have longer livespans and the 3 1/2" floppy is
a long-lived and ubiquitous standard format. But of course they
are also the kind of technology that you'd just wish would die, but
it doesn't! :)

> Some samplers are starting to use flash cards instead, which gives you
> more storage but less portability (at least right now).

Someone wondered on one of the E-mu mailing lists why E-mu didn't use
smart memory or flash cards that are becoming common, and an E-mu
employee responded that the memory isn't even nearly fast enough.

Anyway...

> I can write samples that the SU can read about half the time. The
> other half of the time it just gives an error. And when it works, the
> sample takes up all available memory until I use the SU's "trim"
> function, after which it takes up the expected amount of memory. So
> maybe one of the mystery parts of the header tells the SU how much
> memory to allocate.

This sounds similar to the .wav file format, in which some of the
information that is encoded in the header is implicitly defined
elsewhere, or can be determined from other header fields. If that
is the case for you, then you're definitely in luck.

Now, when you send your own file off to the unit, are you clearing
the header bytes that you don't understand? It may be that all zeros
are interpreted as "don't know" (so allocate everything and hope) or
as "the whole thing". One thing to try is to treat the mystery header
bytes as an array of 8 or 16 bit numbers, then throw all 1's or other
values in to see how the behavior changes. It might be just one 8, 16
or 32-byte field in there is for the sample size, and you can figure
out which. Divide and conquer!

- Jay Ts


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 03:44:22 EET