Playing audio backwards?

Bob Reynolds · 2013-05-28 13:01

Has anyone tried playing an audio file backwards, with a propeller?

I'd like to build a science museum exhibit which duplicates a process I used to do with tape:
Record a spoken phrase
Flip the tape around and play the phrase backwards
Learn (as best you can) to speak the backwards sounds
Record the backwards speech
Flip the tape again and play it
Hilarity ensues, as I remember (there may have been herbs involved - it WAS 1972)!

Phil Pilgrim (PhiPi) · 2013-05-28 13:08

As long as the audio file is uncompressed, it should not be a problem: just start at the end and work your way back. Compressed files that rely on state from a previous frame, though, would be a problem.

-Phil

David B · 2013-05-28 14:33

I've done a little playing around with warbling playback rate, playing the same sound file through multiple channels with varying delays to make an echo effect, but never have tried played sound backwards.

In general, it could be a problem playing an SD FAT file backwards because FAT filesystems don't provide a way to track sectors in reverse; the sectors are linked with just a forward chain.

But if the sectors have been stored contiguously then it shouldn't be too hard to set up a procedure to retrieve the sectors in reverse, then come up with a way to play each sector in reverse.

Rayman · 2013-05-28 16:14

I have a "parrot" demo that works with Propeller Demo board or equivalent. It records low quality, small sample speech to HUB RAM and then randomly plays back either a new speech or a different recorded one...

That would be easy to make play backwards.
Playing back from SD might be trouble, as David says.
You could easily use an SRAM chip if you need more space though...

SRLM · 2013-05-28 16:54

You could also use a small Linux box to record and play the sound backwards.

(record 15 seconds of CD quality audio to the output.mp3 file, then play it back in reverse)

arecord -f cd -d 15 output.mp3
play output.mp3 reverse

You can then just toss this into a Bash script that loops and does anything else that you need to get done.

edit: BTW, it's really fun doing your game! I didn't realize that I made all those weird noises when I spoke, and I suppose it gives me a taste of what English sounds like to non-native speakers.

Phil Pilgrim (PhiPi) · 2013-05-28 19:54

I checked fsrw and notice that it has a seek method which, in theory, could be used to index through a file in reverse. However, in fsrw, seek works only within the currently accessed cluster, so it would need to be modified -- maybe a simple mod -- to work across multiple file clusters, assuming it would be fast enough for audio.

It might make more sense to partition the SD card into FAT and non-FAT sections and use lower-level code to copy a FAT sound file to the non-FAT partition as one monolithic block of data. Then that could be read in reverse quite easily. Or just dispose with a filesystem altogether if a single block of sound data is all that has to exist on the SD card.

-Phil

David Betz · 2013-05-28 19:59

Phil Pilgrim (PhiPi) wrote: »

I checked fsrw and notice that it has a seek method which, in theory, could be used to index through a file in reverse. However, in fsrw, seek works only within the currently accessed cluster, so it would need to be modified -- maybe a simple mod -- to work across multiple file clusters, assuming it would be fast enough for audio.

It might make more sense to partition the SD card into FAT and non-FAT sections and use lower-level code to copy a FAT sound file to the non-FAT partition as one monolithic block of data. Than that could be read in reverse quite easily. Or just dispose with a filesystem altogether if a single block of sound data is all that has to exist on the SD card.

-Phil

If you're willing to consider writing your code in C, the PropGCC SD filesystem code can handle seeking anywhere in a file. I'm sure the same is true of Catalina C.

SRLM · 2013-05-28 20:45

Phil Pilgrim (PhiPi) wrote: »

I checked fsrw and notice that it has a seek method which, in theory, could be used to index through a file in reverse. However, in fsrw, seek works only within the currently accessed cluster, so it would need to be modified -- maybe a simple mod -- to work across multiple file clusters, assuming it would be fast enough for audio.

-Phil

Apparently, this is fixed:

Dave Hein wrote: »

FSRW 2.6 can do a random seek if the file is open for read. The comment about seek not working in the code is a leftover from the earlier version of FSRW.

http://forums.parallax.com/showthread.php/143130-FSRW-pread-question

Phil Pilgrim (PhiPi) · 2013-05-28 20:52

Excellent! But is it fast enough to play audio?

-Phil

Kye · 2013-05-28 21:00

Trying to read a file backwards will result in a massive performance hit. Not only will you not get the multi-block speed up but the FAT will have to re-traversed for each cluster from the beginning.

If you can buffer the whole file, then it is a different matter... but, you'll need a lot of memory then.

Phil Pilgrim (PhiPi) · 2013-05-28 21:21

Kwabena,

Would it be possible to make a cluster address list ahead of time in RAM in order to avoid the performance hit? If so, you could traverse the clusters in reverse without having to scan from the beginning each time.
______________

OTOH, even with a performance hit, one could simply copy the file in reverse order before attempting real-time playback.

-Phil

Kye · 2013-05-29 06:34

Yeah,

You could do that. The trick is that it will be more work then (o_O)!

You could get non-multi block access speeds. So, the same speed as my file system driver which is just enough to play a file.

I have a private function in my code that actually does this for you. You just give it a file name and it will give you the list of file clusters. Assuming the disk has 64 K clusters then the list will not be so large. 1024 longs for a 64 MB file.

rokicki · 2013-05-29 14:16

I suspect you wouldn't actually have too many problems if you used
reasonably sized buffers. Say, use a 16K buffer and read backwards
in chunks of 8K; half the buffer is playing and half the buffer is being
read into.

Assuming your cluster size is large (32k) and your sample rate is
small enough, this should be plenty fast. An 8K chunk comes in
pretty fast.

Just don't try to read backwards in small chunks (512 or less).

If your cluster size is small, then all bets are off.

If there will be any challenge, it will be getting a reliable write
(record); the SD card can stall for a fairly good amount of time on
any arbitrary write. It will be rare, but write delays of for instance a
half second are quite possible. The card is doing a *lot* of stuff
inside and once in a while you catch it out of erased blocks or
in the middle of a required data copy or some such. For this a
big buffer helps too. Indeed, it may be necessary to use a
larger buffer than fits in hub ram to reliably record without gaps.

This sounds like fun and some day I'll get a chance to play . . .

tom

Phil Pilgrim (PhiPi) wrote: »

Kwabena,

Would it be possible to make a cluster address list ahead of time in RAM in order to avoid the performance hit? If so, you could traverse the clusters in reverse without having to scan from the beginning each time.
______________

OTOH, even with a performance hit, one could simply copy the file in reverse order before attempting real-time playback.

-Phil

VIRAND · 2013-06-01 23:06

This might do what you want, however the sound quality is sacrificed in favor of maximizing the recording time in the internal RAM of the Propeller,
but it does demonstrate recording and playing and backwards on a DEMOBOARD, and you decide if it's of any use.

Toby Seckshund · 2013-06-02 01:09

Somebody has to say it ...

If you use the Prop to play the sound backwards, then you would hear its evil plan for world donination mixed in ...

Yeah I'm at work, yeah its quiet ...

Playing audio backwards?

Comments