RE: [stella] music compression

Subject: RE: [stella] music compression
From: "Pension Maricel" <Maricel@xxxxxxxxxx>
Date: Mon, 5 Apr 1999 17:38:01 +0200
see our web page

Pension Maricel
C. Tacó nº 13
Sitges 08870
Tel.  938-943-627
Fax 938-943-869

-----Mensaje original-----
De: cwilkson@xxxxxxx <cwilkson@xxxxxxx>
Para: stella@xxxxxxxxxxx <stella@xxxxxxxxxxx>
Fecha: lunes 5 de abril de 1999 9:59
Asunto: Re: [stella] music compression

>>>Have you considered creating your own waveforms?
>>Yes.  Sorry I left out the juicy bits about the design of the sound
>>I figured I would tinker with it first, but I haven't updated it since my
>>original post so I might as well describe what it is as of now.
>Hmmm.  I didn't mean *fancy* waveforms.  Just squarewaves.  That leaves
>time for other stuff, but can be expanded if desired.  If you're doing a
>squarewave playback, then you only have to deal with note information, not
>waveform re-creation.
>>The "fancy" part of this table lookup is that the frequency is a 16 bit
>>fixed point
>>value, with the lower 8 bits as the fractional part.
>>The position is also a 16 bit fixed value.  The top half is used to index
>>wavetable.  The bottom half is used to keep track of a "fractional"
>[other stuff deleted]
>This describes one of my 6.111 (Digital Death Lab) projects from last
>We took an audio signal in and dynamically changed the frequency, but NOT
>tempo of whatever was playing.  As you note, lowering a frequency is much
>cleaner than raising it. :)
>>>  This allows you to use any
>>>frequency you want.  If you only update the sound registers once per
>>>you get 0 to 15.7kHz, or 8 (resonable) octaves.  If you update every
>>>scanline, you get a top end of 7.85kHz...still not bad.
>>A synthesis model like mine requires 1 to 2 lines of compute time.
>>A strictly 2 chan. wavetable sample model can be pulled off in 1 line (I
>Yeah, I was assuming squarewaves only.  It was unclear exactly what you
>trying to do.
>>>Also, let's assume that no voice ever jumps more than an octave.  If you
>>>use relative motion, with chromatic scales, you need 3.5 bits of storage
>>>for each voice, and you give each voice a total range of 4 octaves
>>Can you explain this?  Assume you stay the same, that's "0"
>Well, I told you I was tired when I sent this.  But who needs voices to
>DOWNWARD?  Just keep building the tension.  And building...and building...
>So 4.5 bits is correct. Sorry. :(
>>>(conservative 2-scanline approach).  Also, since (I assume) you're doing
>>>2 voices per channel, if you're just re-writing the volume data for each
>>>channel, you can store the information in terms of channels instead of
>>>voices.  Doing this gives double the storage resolution, or 1.75 bits
>>>per voice, per beat.
>>Are you confusing the wavetable sample with note information?
>>I don't see how I can combine the musical information for two voices
>>into one channel.  (Other than wavetable precomputation, which is a
>>different matter than musical note data for a song).
>Again, I was not thinking is terms of samples.  So assuming you just have
>a SW synth, you still get 2:1 compression, or 2.25 bits/voice.  You can
>add them together.  This works (I think) for any waveform.  But if the 2
>waveforms are different, then it gets ugly.  Won't work without
>Which isn't a bad idea, BTW.  If you're just doing a composition tool.  But
>if you want it to work in a game, I think you'd want to precompute the
>soundtrack, and store it in the rom.  I think you mentioned this somewhere.
>>Or maybe it's time to think about a different problem, like a more samples
>>oriented engine as described above.  But thank you for posting it and
>>help me understand some of your ideas on this.
>Yeah, I think we were speaking 2 different languages. :)
>We should get together and brainstorm this.  I don't think well in front of
>a keyboard.  Or maybe because it's almost 3:00am.  I dunno...probably both.
>Archives (includes files) at
>Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread