Digitized Sounds

[jacobus]

The Quick programming manual references a digitizer described in an Atari magazine from 1989 (please see the quote below). Does anyone have such a device, or perhaps even better, does anyone have any experience converting a digitized sound recorded on a PC to the described format? Thank you!

 

 

 

The data must be in a special format as defined in ATARI magazine 1/1989 and 5/1989 by PPP Germany
(there you can also find how to build a sound sampler for the XL/XE computers). The format looks like this:
Two 4-bit sound data are put into one byte. The first data is put in the high nibble, the second in the low nibble
of the byte. The third sound data is put in the high nibble of the second byte and so on. Samples from Parrot,
Replay, Digi-Studio, and Antic Sampling Processor are fine.

 

[Rybags]

4 bit samples packed as described is pretty much the norm.

 

PC utilities will often only support down to unsigned 8-bit samples. Not a problem really, you can just output 8-bit samples to a file then write a little program on the Atari which reads it and outputs to packed 4-bit as required.

 

When possible, output as raw data from the PC, you don't want to include stuff like .WAV headers.

[phaeron]

I couldn't help but cringe when I saw someone downconverting a sound file to 4-bit through an Atari BASIC program running on an emulator. There are so many better and easier ways to do this directly on the PC -- C, Python... heck, you can even do it in MADS.

 

A decent audio tool like Audacity will let you clean up the sound (high-pass, normalize, compress) and resample it to target sample rate much better than a quick-and-dirty tool will. Don't do it by averaging samples together -- that's called a box filter and it's awful, particularly for the low rates you need to target. The 8-bit is not going to be playing high quality sound if it's doing anything else, but if you're going to do it, you might as well get as much out of 4 bits of volume and 4-8KHz sampling rate as you can.

 

[Rybags]

Similarly, playback technique has a large bearing.

 

Delay loops, minimised graphics or DMA off completely is the old primitive way.

 

Pokey Timers is the modern way, you can do IRQ playback which will be practically as good as screen-off. Although it's not something that a HL language will do natively, assembler is a must there.

[Heaven/TQA]

I had the mentioned digitizer which I used to sample the Please wait sample from Atari ST wings of death loading animation. I used it in one of the later demos of mine.

 

For Gridrunner I have used audacity and Miker prepared the samples.

[snicklin]

Does anyone have (or know a link to) a guide on using Audacity to create 4kHz samples? I'm playing with it on Linux Mint but it's not as easy to use as Virtualdub.

 

After this, does anyone know of a scripted way to remove the wav header automatically and then make them into 4 bit samples?

 

I tend to work by having the raw data which has come out of a PC application and then use a build system which strips out / converts data.

 

That way if the sample is changed, the build system just extracts the right data each and every time, without having to manually strip it out.

[Rybags]

Audacity lets you do raw data saves, don't have it installed ATM but I think it's in the Export option, plus you have to change format within the preferences.

 

Also not sure what the limit on frequency is - fairly sure you can use anything from 0-200,000.

[Heaven/TQA]

Isn't there to consider stuff like signed unsigned with raw data?

[Rybags]

You should get the option to have signed/unsigned. Unsigned for Atari of course.

 

 

[ivop]

Does anyone have (or know a link to) a guide on using Audacity to create 4kHz samples? I'm playing with it on Linux Mint but it's not as easy to use as Virtualdub.

 

After this, does anyone know of a scripted way to remove the wav header automatically and then make them into 4 bit samples?

 

I tend to work by having the raw data which has come out of a PC application and then use a build system which strips out / converts data.

 

That way if the sample is changed, the build system just extracts the right data each and every time, without having to manually strip it out.

 

Generally speaking, you should remove all frequencies above half of the replay rate. So, for example if you want to play the sample at 7.6kHz (i.e. one sample every scan line), you can use a low-pass filter at 3.8kHz. To be on the safe side, set it to 3.5kHz and suppress the higher frequencies as much as possible (i.e. -24dB or something). You can also suppress the lower frequencies, say below 100Hz, which will avoid the sound being drowned. After that, optionally run the sample through a limiter/compressor to make the loud passages quieter and the quiet passages louder. Remember you have only 4 bits times ca. 6dB = 24 dB of dynamic range. Thereafter, normalize everything to 0dB (i.e. maximum peak amplitude), convert to 7600Hz and save as 8-bit mono unsigned raw.

 

On the Atari side, you can cut off the lower 4 bits. Perhaps it would sound better if the converter uses dithering, though I'm not sure if that helps if there are only four bits dynamic range.

[Rybags]

I tried dither/oversample once, ie play an intermediate sample which is average of current/next, for slight improvement but you pay with more CPU time lost.

 

In theory you could do the 5-bit sample method, add current + next and use the result, for no extra memory cost, but of course the greater CPU expenditure.

[jacobus]

Thank you all for the quick responses!

 

I tried Audacity on a very short drip sound - the smallest I could make the file was 13K - and it sounded only slightly better than the non digitized sound I was using already. Even after removing the header and using Quick's compression method, the amount of data will be way too large. I will have to re-think the use of digitized sounds in my project.

[Rybags]

2-bit samples is another option although the loss of quality can make it barely worth the effort.

[Heaven/TQA]

What does Sheddy use in Space Harrier? And how to setup Pokey timers?

 

And... If I use pokey timers for playing samples I am loosing 1 channel for sound?

[Rybags]

Sheddy uses Timers - I think by direct IRQ method with Ram-based OS which has lower overhead.

 

You lose a voice regardless - just use the Timer associated with the given voice, so there's no loss really, although voice 3 has no timer.

 

In theory you should be able to have a 16-bit voice pairing and use the low voice for digital output since normally you leave it silent.

Of course though, you still have the problem that it needs a Timer, although you could just resort to delay loop method.

[Heaven/TQA]

Need to check my Gridrunner sources as I am using Sheddy's methods.... Long time I have seen the source just forgot...

[ctirad]

I tried dither/oversample once, ie play an intermediate sample which is average of current/next, for slight improvement but you pay with more CPU time lost.

It would be nice to make some precise measurements of the pokey volume channel characteristics and make a convolution matrix filter for sox or similar software in order to produce best possible sounding samples.

 

With today mass storage drives and RAM expansions there is a plenty of space for loop based sountracks without needs of pitch or volume calculations and thus leaving CPU cycles for something more useful.

[_The Doctor__]

Sheddy's approach was very nice it played just fine without requiring mass storage and mods etc...

I played the original beta levels off of floppy disk....

I mean it's nice that we have 1 meg memory and fast large drives and all but I think weaving some nice samples into a game or app of any kind that will work on standard equipment and with that quality...

he provided everything to the public so it could be looked at and replicated...

He moved it all to cartridge when the music was redone (RMT), the gameplay stayed the same just no wait time for disk access at major level changes, I really did not mind sliding in a floppy (it gave my hand a rest) and the method was used to make tempest extreme digitised sound later on as the same fellow who converted the music employed the methods to his own works.

Edited October 18, 2014 by _The Doctor__

[_The Doctor__]

https://atariwiki.org/wiki/Wiki.jsp?page=Ironman%20Atari#section-Ironman+Atari-PushingPOKEY

 

in this page find digitized section sheddy non-irq and irq snippet

 

two different ways to skin the same cat...

 

I ignored the expired warning about invalid certificate... didn't hurt me a bit!

Edited October 18, 2014 by _The Doctor__

[Rybags]

RMT by default doesn't support sample playback.

 

Sheddy changed to IRQ playback after consultation with people on this forum including me. Such playback routines are DIY efforts, in any case you have to make them application specific and as compact and fast as possible to do synchronous playback.

[pps]

I own one of such devices. In fact it is the Sound'n'sampler device, but it is similar to the one that was described in the magazine.

 

If you want, I can test, if it still works and put then some test samples here.