Hi all,
I have to compress some wav files with an algorithm, the resulting files will be written to a flash of a microcontroller. I have to decompress these files with the microcontroller and play them as simple wave files.
So there are some crucial things:
- the speed is not so awesome (16 MHz)
- I have to be very careful with the system load, therefore I can't really use complex instructions.
So the major goal is to decode in minimum time with the smallest system load possible. The encoding will be done on a PC, so it doesn't matter too much.
I'm kind of newbie in compression algorithms, so I am not sure if I should seek lossless or lossy algorithms for a better result.
If some of you could help me which algorithms might be tried in my case, that'd be great.
Oh, and there's another thing: the source code should be available, because I have to implement it.
Thanks
Full Version: Compression/Decompression on Embedded Systems
I would consider using something like ADPCM, instead of a more complex compression solution. It won't give you anywhere near the quality per kilobyte you would get with MP3 or similar, but it is very easy to decode with fairly little processing power. Google will be able to point you in the direction of plenty of information on ADPCM and related methods.
Ok, I'll try ADPCM. Thanks for the quick reply.
I forgot to mention that I have to deal with only 4, 8, 12, 16 kHz, 8 bit per sample waves, not CD quality waves.
I forgot to mention that I have to deal with only 4, 8, 12, 16 kHz, 8 bit per sample waves, not CD quality waves.
it might be helpful to know which microcontroller u r using. also, it will be helpful to know how much memory u have attached to the controller. this will help in decide how large the codec size can be. plus dont forget, u need memory to store intermediate data and decompressed data before it is dumped to the IO.
im suggesting this, bcoz even i would like to know what experts on the forum have to say about the choice of codecs for such a project and how the system constraints influence the selection.
siddharth
Hi all,
I have to compress some wav files with an algorithm, the resulting files will be written to a flash of a microcontroller. I have to decompress these files with the microcontroller and play them as simple wave files.
So there are some crucial things:
- the speed is not so awesome (16 MHz)
- I have to be very careful with the system load, therefore I can't really use complex instructions.
So the major goal is to decode in minimum time with the smallest system load possible. The encoding will be done on a PC, so it doesn't matter too much.
I'm kind of newbie in compression algorithms, so I am not sure if I should seek lossless or lossy algorithms for a better result.
If some of you could help me which algorithms might be tried in my case, that'd be great.
Oh, and there's another thing: the source code should be available, because I have to implement it.
Thanks
im suggesting this, bcoz even i would like to know what experts on the forum have to say about the choice of codecs for such a project and how the system constraints influence the selection.
siddharth
QUOTE(Lacoona @ Apr 26 2006, 04:09 PM) 
Hi all,
I have to compress some wav files with an algorithm, the resulting files will be written to a flash of a microcontroller. I have to decompress these files with the microcontroller and play them as simple wave files.
So there are some crucial things:
- the speed is not so awesome (16 MHz)
- I have to be very careful with the system load, therefore I can't really use complex instructions.
So the major goal is to decode in minimum time with the smallest system load possible. The encoding will be done on a PC, so it doesn't matter too much.
I'm kind of newbie in compression algorithms, so I am not sure if I should seek lossless or lossy algorithms for a better result.
If some of you could help me which algorithms might be tried in my case, that'd be great.
Oh, and there's another thing: the source code should be available, because I have to implement it.
Thanks
I have 64k space (max 128 k) for the data and these sounds have max. couple of seconds length, but I think in most of the cases ~1s.
it might be helpful to know which microcontroller u r using. also, it will be helpful to know how much memory u have attached to the controller. this will help in decide how large the codec size can be. plus dont forget, u need memory to store intermediate data and decompressed data before it is dumped to the IO.
im suggesting this, bcoz even i would like to know what experts on the forum have to say about the choice of codecs for such a project and how the system constraints influence the selection.
siddharth
Hi all,
I have to compress some wav files with an algorithm, the resulting files will be written to a flash of a microcontroller. I have to decompress these files with the microcontroller and play them as simple wave files.
So there are some crucial things:
- the speed is not so awesome (16 MHz)
- I have to be very careful with the system load, therefore I can't really use complex instructions.
So the major goal is to decode in minimum time with the smallest system load possible. The encoding will be done on a PC, so it doesn't matter too much.
I'm kind of newbie in compression algorithms, so I am not sure if I should seek lossless or lossy algorithms for a better result.
If some of you could help me which algorithms might be tried in my case, that'd be great.
Oh, and there's another thing: the source code should be available, because I have to implement it.
Thanks
QUOTE(siddharth vaghela @ Apr 26 2006, 12:52 PM)
it might be helpful to know which microcontroller u r using. also, it will be helpful to know how much memory u have attached to the controller. this will help in decide how large the codec size can be. plus dont forget, u need memory to store intermediate data and decompressed data before it is dumped to the IO.
im suggesting this, bcoz even i would like to know what experts on the forum have to say about the choice of codecs for such a project and how the system constraints influence the selection.
siddharth
QUOTE(Lacoona @ Apr 26 2006, 04:09 PM)
Hi all,
I have to compress some wav files with an algorithm, the resulting files will be written to a flash of a microcontroller. I have to decompress these files with the microcontroller and play them as simple wave files.
So there are some crucial things:
- the speed is not so awesome (16 MHz)
- I have to be very careful with the system load, therefore I can't really use complex instructions.
So the major goal is to decode in minimum time with the smallest system load possible. The encoding will be done on a PC, so it doesn't matter too much.
I'm kind of newbie in compression algorithms, so I am not sure if I should seek lossless or lossy algorithms for a better result.
If some of you could help me which algorithms might be tried in my case, that'd be great.
Oh, and there's another thing: the source code should be available, because I have to implement it.
Thanks
Mmm... that's a very small memory you got there. I think I'll second cabbagerat.
If you can provide more RAM, check out TrueAudio. It is open source, GPL. The makers claim that it is specifically designed for easy hardware implementation - not necessarily maximum overall compression levels. My tests seems to bear this: the TTA is the fastest encoder ever; almost twice the speed of FLAC -5, and still 25% faster than WavPack -f. The file size is smaller than FLAC --super-secret.
If you can provide more RAM, check out TrueAudio. It is open source, GPL. The makers claim that it is specifically designed for easy hardware implementation - not necessarily maximum overall compression levels. My tests seems to bear this: the TTA is the fastest encoder ever; almost twice the speed of FLAC -5, and still 25% faster than WavPack -f. The file size is smaller than FLAC --super-secret.
QUOTE(pepoluan @ Apr 26 2006, 02:42 PM)
My tests seems to bear this: the TTA is the fastest encoder ever; almost twice the speed of FLAC -5, and still 25% faster than WavPack -f.
Other tests aren't confirming this:
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm [TTA = x30; WavPack¹ = x35; Flac = x40]
http://members.home.nl/w.speek/comparison.htm [TTA = x23; WavPack² = x28; flac = x44; shorten = x70]
http://guruboolez.free.fr/lossless/ [TTA = x22; WavPack = x46; flac = x46; shorten = x80]
So accorded to these tests, the fastest lossless decoder/format is by far shorten (which compresses with a poor ratio) and clearly not TTA.
Other very fast format: MPEG-1 layer 1 and MPEG-1 layer 2
¹ Hans used an old and unoptimized WavPack decoder; a faster one [4.2] was released by Bryant later.
² Value is for WavPack -normal, not -fast
You might want to check out the application note of an ADPCM-decoder by Atmel, it uses similar (or maybe even same, if you are real lucky) hardware that you are working with: http://www.atmel.com/dyn/resources/prod_do...nts/doc2572.pdf
I have managed to play uncompressed small wave tables using the microcontroller's internal sound generator. This controller doesn't use any dsp functions, only simple ones. The key feature was to generate interrupts at every sample time, then the wave amplitude data is sent out. At 8kHz the processor load is arround 4-5%, the runtime of an interrupt is arround 6 microseconds. However i'm sure after an implementation of a compression algorithm it will increase significantly.
So I am seeking for an algorithm where I can replace divisions and multiplications with register shifts, which uses no floating point operations.
Thanks for the replys
So I am seeking for an algorithm where I can replace divisions and multiplications with register shifts, which uses no floating point operations.
Thanks for the replys
QUOTE(Lacoona @ Apr 26 2006, 04:10 PM)
I have managed to play uncompressed small wave tables using the microcontroller's internal sound generator. This controller doesn't use any dsp functions, only simple ones. The key feature was to generate interrupts at every sample time, then the wave amplitude data is sent out. At 8kHz the processor load is arround 4-5%, the runtime of an interrupt is arround 6 microseconds. However i'm sure after an implementation of a compression algorithm it will increase significantly.
So I am seeking for an algorithm where I can replace divisions and multiplications with register shifts, which uses no floating point operations.
Thanks for the replys
Hi,
Better forget about lossless compression, it gives variable compression ratio, and at lower sampling rates, it will not perform well.
I recommend you try 4-bit ADPCM, it will give you a constant 2:1 compression ratio, storing each sample in 4 bits, without floating-point operations
By the way, since you will deal with 8 bit-per-sample sound, don't forget to normalize the audio sequences, in order to use most of your range: -128..127
Edit: Have a look there: http://www.itu.int/rec/T-REC-G.726/e
QUOTE(guruboolez @ Apr 26 2006, 08:53 PM)
QUOTE(pepoluan @ Apr 26 2006, 02:42 PM)
My tests seems to bear this: the TTA is the fastest encoder ever; almost twice the speed of FLAC -5, and still 25% faster than WavPack -f.
Other tests aren't confirming this:http://web.inter.nl.net/users/hvdh/lossless/lossless.htm [TTA = x30; WavPack¹ = x35; Flac = x40]
http://members.home.nl/w.speek/comparison.htm [TTA = x23; WavPack² = x28; flac = x44; shorten = x70]
http://guruboolez.free.fr/lossless/ [TTA = x22; WavPack = x46; flac = x46; shorten = x80]
So accorded to these tests, the fastest lossless decoder/format is by far shorten (which compresses with a poor ratio) and clearly not TTA.
Other very fast format: MPEG-1 layer 1 and MPEG-1 layer 2
¹ Hans used an old and unoptimized WavPack decoder; a faster one [4.2] was released by Bryant later.
² Value is for WavPack -normal, not -fast
I use WavPack 4.31 (MD5: d8825f0667d4ecd33641d1926d52a1f1) and TTAenc 3.3 (MD5: eef0e25088d8c687e790c67f447048c8). And I don't compress snippets of sound, I compress whole tracks. Although not of classical music, but mostly hip-hop, rock, hard-rock, and many JPop and pop musics.
I can vouch that the absolute majority, even nearly all the time, TTAenc compresses faster than WavPack. It lost in compression ratio to WavPack -h, but it beats the compression ratio of WavPack -f.
Edit:As to shorten, I don't know if it will be faster or not.
Edit2:Stupid typo. Fixed now. See strikethrough above.
QUOTE(pepoluan @ Apr 26 2006, 08:07 PM)
Ah yes, but you have to note the date, M guruboolez
I know the date. What matters is the version of the encoder. TTA is not really often updated.
QUOTE
And I don't compress snippets of sound, I compress whole tracks. Although not of classical music, but mostly hip-hop, rock, hard-rock, and many JPop and pop musics.
Speek = 10 full albums and complete results available here.
Hans Heijden = 7 full albums and complete results available
guruboolez = 20 full albums and complete results available here
pepoluan = ? tracks and zero result available - not even one measurement. Or am I wrong?
So if you have results that are going against the experience of three persons, who all have published complete details of the methodology and the material used for the test, it would be nice to see something else that vague claims without any documentation. It would help the whole community. Thanks
QUOTE(pepoluan @ Apr 26 2006, 02:07 PM)
Edit:As to shorten, I don't know if it will be faster or not. Perhaps not. But OP definitely wants an open-source algorithm. And small size. TTA's encoder & decoder fits into a 94kO file, while WavPack's encoder & decoder are separate files for a total of 266 kO.
no one suggested wavpack for the application. you brought up TTA (which is also unsuitable due to complexity and maybe size) and then compared it to wavpack, along with other things that don't make sense ("it is specifically designed for easy hardware implementation - not necessarily maximum overall compression levels" -- so were FLAC and wavpack).
QUOTE(guruboolez @ Apr 27 2006, 02:39 AM)
So if you have results that are going against the experience of three persons, who all have published complete details of the methodology and the material used for the test, it would be nice to see something else that vague claims without any documentation. It would help the whole community. Thanks
Hehe well I've encoded 38 full tracks now. And I expect to reach up to 60 tracks. Results will be posted in HA wiki when all the tracks have been encoded. Since I have to timeshare my computer with other members of the family, naturally I have to interrupt encoding whenever others want to use my computer.It seems I have underestimated the time required for testing.
QUOTE
you brought up TTA (which is also unsuitable due to complexity and maybe size) and then compared it to wavpack, along with other things that don't make sense ("it is specifically designed for easy hardware implementation - not necessarily maximum overall compression levels" -- so were FLAC and wavpack).
Well that was not my claim, but the TTA site's. If there's enough memory and processing power, I'd suggested FLAC. But since there's an issue of memory and processing power, naturally I lean on the smallest binary implementation (means less ROM usage), and fastest encoding speed (means less CPU load).Well anyways, like I written above:
QUOTE
Mmm... that's a very small memory you got there. I think I'll second cabbagerat.
Due to such memory (& processor) constraint, then ADPCM should suffice.QUOTE(pepoluan @ Apr 26 2006, 09:23 PM)
Well that was not my claim, but the TTA site's.
And you repeat them?
TTA websites also claimed in the past 2 or 3% better compression than Monkey's audio - basing this fact on a intentionally biased set of albums. Therefore, I would be very critical before suscribing to any of their claims. Recently they announced 40% speed-up. It's nice, but the optimized encoder (or decoder) doesn't seem available... Moreover, the speed-up is for hyper-threading and dual-core: not exactly the kind of hardware setting lacoona is looking for. And to finish, TTA should be at least 150 to 200% faster than what was tested by Hans, Speek and myself to compete with WavPack or flac. Such improvement wasn't announced at all by TTA's developers.
It's not that I don't believe your own experience but what you claimed is going against what was tested in the past by several people and also go against TTA's changelog. So there's something difficult to understand.
I tried to compare speed again with the latest TTA & flac official tools. I just did it with one file.
ttaenc.exe -t is amazingly fast: it has tested the whole file in less than 1 sec (0.721). The average speed corresponds to x785! I guess that the -t mode performs something like a md5 or CRC verification and doesn't decode the file at all (the CPU doesn't even reach 50%). Therefore, the file has to be decoded as .wav file, making the process highly dependent of the fragmentation (my laptop is very fragmented...).
That's why I performed two kind of test: the first one with CLI decoders and timethis, and the second one with foobar2000 0.83 diskwriter. Results:
The decoding process was highly affected by the disk access: it was a kind of stop-and-go during the whole process. I performed 5 pass and kept the best result for both format. TTA is 80% slower than FLAC.
With foobar2000 diskwriter, which is completely free of disk access contingencies, TTA appear to be 300% slower.
I don't know: how did you based the speed computation? With -t "switch" for both flac and ttaenc? They correspond for both tools to a TEST process but the testing procedure is completely different. Anyway, things haven't changed since two years: TTA is absolutely not in the same category than WavPack -f and FLAC and the latters look clearly more suitable for hardware implementation.
EDIT: tested on laptop with AMD Athlon 2000+ or something like that.
ttaenc.exe -t is amazingly fast: it has tested the whole file in less than 1 sec (0.721). The average speed corresponds to x785! I guess that the -t mode performs something like a md5 or CRC verification and doesn't decode the file at all (the CPU doesn't even reach 50%). Therefore, the file has to be decoded as .wav file, making the process highly dependent of the fragmentation (my laptop is very fragmented...).
That's why I performed two kind of test: the first one with CLI decoders and timethis, and the second one with foobar2000 0.83 diskwriter. Results:
CODE
TimeThis foobar2000 0.83
TTA 20.088 sec 17.636 sec.
FLAC -8 12.367 sec 4.847 sec.
reference file length: 9min. 26sec. 800ms.
TTA 20.088 sec 17.636 sec.
FLAC -8 12.367 sec 4.847 sec.
reference file length: 9min. 26sec. 800ms.
The decoding process was highly affected by the disk access: it was a kind of stop-and-go during the whole process. I performed 5 pass and kept the best result for both format. TTA is 80% slower than FLAC.
With foobar2000 diskwriter, which is completely free of disk access contingencies, TTA appear to be 300% slower.
I don't know: how did you based the speed computation? With -t "switch" for both flac and ttaenc? They correspond for both tools to a TEST process but the testing procedure is completely different. Anyway, things haven't changed since two years: TTA is absolutely not in the same category than WavPack -f and FLAC and the latters look clearly more suitable for hardware implementation.
EDIT: tested on laptop with AMD Athlon 2000+ or something like that.
TTA checkmate
Thanks to Seldaek, a TTA input decoder was easy to find for foobar2000 0.9.1.
I performed a 6 pass decoding test, with file buffering and high priority, for:
- flac 1.1.2.1 -8
- tta 3.3
- WavPack 4.31 -fx5
Settings:
Buffer entire file into memory: yes
High priority: yes
Passes: 6
File: C:\Converted Music\kantate_flac.flac
Run 1:
Length: 9:26.799
Opening time: 0:00.199
Decoding time: 0:03.666
Speed (x realtime): 154.580
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:03.664
Speed (x realtime): 154.673
Run 3:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.697
Speed (x realtime): 153.299
Run 4:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.709
Speed (x realtime): 152.794
Run 5:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.710
Speed (x realtime): 152.748
Run 6:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.676
Speed (x realtime): 154.172
Total:
Opening time: 0:00.000 min, 0:00.199 max, 0:00.034 average
Decoding time: 0:03.664 min, 0:03.710 max, 0:03.687 average
Speed (x realtime): 152.748 min, 154.673 max, 153.707 average
File: C:\Converted Music\kantate_tta.tta
Run 1:
Length: 9:26.799
Opening time: 0:00.225
Decoding time: 0:17.031
Speed (x realtime): 33.278
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.109
Speed (x realtime): 33.128
Run 3:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.074
Speed (x realtime): 33.195
Run 4:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.044
Speed (x realtime): 33.254
Run 5:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.067
Speed (x realtime): 33.209
Run 6:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.111
Speed (x realtime): 33.124
Total:
Opening time: 0:00.000 min, 0:00.225 max, 0:00.037 average
Decoding time: 0:17.031 min, 0:17.111 max, 0:17.073 average
Speed (x realtime): 33.124 min, 33.278 max, 33.198 average
File: C:\Converted Music\kantate_WavPack.wv
Run 1:
Length: 9:26.799
Opening time: 0:00.254
Decoding time: 0:04.414
Speed (x realtime): 128.398
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.415
Speed (x realtime): 128.364
Run 3:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.426
Speed (x realtime): 128.045
Run 4:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.420
Speed (x realtime): 128.222
Run 5:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.437
Speed (x realtime): 127.731
Run 6:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.414
Speed (x realtime): 128.393
Total:
Opening time: 0:00.000 min, 0:00.254 max, 0:00.042 average
Decoding time: 0:04.414 min, 0:04.437 max, 0:04.421 average
Speed (x realtime): 127.731 min, 128.398 max, 128.192 average
Total:
Length: 2:50:02.399
Opening time: 0:00.687
Decoding time: 2:31.092
Speed (x realtime): 67.524
In short:
- flac = x153
- tta = x33
- WavPack = x128
These results could depend on the CPU type (Intel/AMD...) and are also dependent to the level of optimization of the input compenent itself. Anyway... TTA is 5 time slower than FLAC. To become "the king" of decoding speed, TTA doesn't only need optimisations but rather a big miracle
EDIT: my apologies to lacoona. This topic should be splitted.
Thanks to Seldaek, a TTA input decoder was easy to find for foobar2000 0.9.1.
I performed a 6 pass decoding test, with file buffering and high priority, for:
- flac 1.1.2.1 -8
- tta 3.3
- WavPack 4.31 -fx5
CODE
Settings:
Buffer entire file into memory: yes
High priority: yes
Passes: 6
File: C:\Converted Music\kantate_flac.flac
Run 1:
Length: 9:26.799
Opening time: 0:00.199
Decoding time: 0:03.666
Speed (x realtime): 154.580
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:03.664
Speed (x realtime): 154.673
Run 3:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.697
Speed (x realtime): 153.299
Run 4:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.709
Speed (x realtime): 152.794
Run 5:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.710
Speed (x realtime): 152.748
Run 6:
Length: 9:26.799
Opening time: 0:00.001
Decoding time: 0:03.676
Speed (x realtime): 154.172
Total:
Opening time: 0:00.000 min, 0:00.199 max, 0:00.034 average
Decoding time: 0:03.664 min, 0:03.710 max, 0:03.687 average
Speed (x realtime): 152.748 min, 154.673 max, 153.707 average
File: C:\Converted Music\kantate_tta.tta
Run 1:
Length: 9:26.799
Opening time: 0:00.225
Decoding time: 0:17.031
Speed (x realtime): 33.278
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.109
Speed (x realtime): 33.128
Run 3:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.074
Speed (x realtime): 33.195
Run 4:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.044
Speed (x realtime): 33.254
Run 5:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.067
Speed (x realtime): 33.209
Run 6:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:17.111
Speed (x realtime): 33.124
Total:
Opening time: 0:00.000 min, 0:00.225 max, 0:00.037 average
Decoding time: 0:17.031 min, 0:17.111 max, 0:17.073 average
Speed (x realtime): 33.124 min, 33.278 max, 33.198 average
File: C:\Converted Music\kantate_WavPack.wv
Run 1:
Length: 9:26.799
Opening time: 0:00.254
Decoding time: 0:04.414
Speed (x realtime): 128.398
Run 2:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.415
Speed (x realtime): 128.364
Run 3:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.426
Speed (x realtime): 128.045
Run 4:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.420
Speed (x realtime): 128.222
Run 5:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.437
Speed (x realtime): 127.731
Run 6:
Length: 9:26.799
Opening time: 0:00.000
Decoding time: 0:04.414
Speed (x realtime): 128.393
Total:
Opening time: 0:00.000 min, 0:00.254 max, 0:00.042 average
Decoding time: 0:04.414 min, 0:04.437 max, 0:04.421 average
Speed (x realtime): 127.731 min, 128.398 max, 128.192 average
Total:
Length: 2:50:02.399
Opening time: 0:00.687
Decoding time: 2:31.092
Speed (x realtime): 67.524
In short:
- flac = x153
- tta = x33
- WavPack = x128
These results could depend on the CPU type (Intel/AMD...) and are also dependent to the level of optimization of the input compenent itself. Anyway... TTA is 5 time slower than FLAC. To become "the king" of decoding speed, TTA doesn't only need optimisations but rather a big miracle
EDIT: my apologies to lacoona. This topic should be splitted.
QUOTE(guruboolez @ Apr 27 2006, 04:32 AM)
I don't know: how did you based the speed computation? With -t "switch" for both flac and ttaenc? They correspond for both tools to a TEST process but the testing procedure is completely different. Anyway, things haven't changed since two years: TTA is absolutely not in the same category than WavPack -f and FLAC and the latters look clearly more suitable for hardware implementation.
EDIT: tested on laptop with AMD Athlon 2000+ or something like that.
Hmmm... this is very strange... I use AMD AthlonXP 2400+, and I do full encode and decode. Not even testing the -t switch. I use command line, fully automated using scripts, and performed multiple times, and take always the lowest time (they don't differ much anyways).EDIT: tested on laptop with AMD Athlon 2000+ or something like that.
Okay, so that I'm not misunderstood here... I'm not defending TTA, I'm not related to TTA developer or somesuch. Heck, my preferred lossless compressors are FLAC and OptimFROG.
I just want to know where might my test setup be wrong.
BTW... I just realize... I'm testing encoding speed and not decoding speed... it's a wholly different result... TTA is not king
Anyways, after quickly performing some tests (mind you, very minor, 3 files, 1min - 3min, clips of the same track) multiple times, WavPack -f is slightly faster than TTA on that track, but less than 10% difference.
Full result from my test corpus has not been finished yet. Maybe sometime next weekend... sorry...
I just want to know where might my test setup be wrong.
BTW... I just realize... I'm testing encoding speed and not decoding speed... it's a wholly different result... TTA is not king
Anyways, after quickly performing some tests (mind you, very minor, 3 files, 1min - 3min, clips of the same track) multiple times, WavPack -f is slightly faster than TTA on that track, but less than 10% difference.
Full result from my test corpus has not been finished yet. Maybe sometime next weekend... sorry...
I read some thing about ADPCM:
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
To pepoluan and guruboolez:
Please start a differrent topic if you want to argue, this topic should be about something else... Thanks
I have managed to play uncompressed small wave tables using the microcontroller's internal sound generator. This controller doesn't use any dsp functions, only simple ones. The key feature was to generate interrupts at every sample time, then the wave amplitude data is sent out. At 8kHz the processor load is arround 4-5%, the runtime of an interrupt is arround 6 microseconds. However i'm sure after an implementation of a compression algorithm it will increase significantly.
So I am seeking for an algorithm where I can replace divisions and multiplications with register shifts, which uses no floating point operations.
Thanks for the replys
Hi,
Better forget about lossless compression, it gives variable compression ratio, and at lower sampling rates, it will not perform well.
I recommend you try 4-bit ADPCM, it will give you a constant 2:1 compression ratio, storing each sample in 4 bits, without floating-point operations
By the way, since you will deal with 8 bit-per-sample sound, don't forget to normalize the audio sequences, in order to use most of your range: -128..127
Edit: Have a look there: http://www.itu.int/rec/T-REC-G.726/e
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
To pepoluan and guruboolez:
Please start a differrent topic if you want to argue, this topic should be about something else... Thanks
QUOTE(NumLOCK @ Apr 26 2006, 06:35 PM)
QUOTE(Lacoona @ Apr 26 2006, 04:10 PM)
I have managed to play uncompressed small wave tables using the microcontroller's internal sound generator. This controller doesn't use any dsp functions, only simple ones. The key feature was to generate interrupts at every sample time, then the wave amplitude data is sent out. At 8kHz the processor load is arround 4-5%, the runtime of an interrupt is arround 6 microseconds. However i'm sure after an implementation of a compression algorithm it will increase significantly.
So I am seeking for an algorithm where I can replace divisions and multiplications with register shifts, which uses no floating point operations.
Thanks for the replys
Hi,
Better forget about lossless compression, it gives variable compression ratio, and at lower sampling rates, it will not perform well.
I recommend you try 4-bit ADPCM, it will give you a constant 2:1 compression ratio, storing each sample in 4 bits, without floating-point operations
By the way, since you will deal with 8 bit-per-sample sound, don't forget to normalize the audio sequences, in order to use most of your range: -128..127
Edit: Have a look there: http://www.itu.int/rec/T-REC-G.726/e
QUOTE(Lacoona @ Apr 27 2006, 06:15 PM)
I read some thing about ADPCM:
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
You have 8bit PCM. You want to compress it, and you want it to be simple. Am I correct?
4bit ADPCM will offer 50% decrease in size with almost zero overhead.
QUOTE(Lacoona @ Apr 27 2006, 03:15 AM)
I read some thing about ADPCM:
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
Yes you are
Please read some more than just the topic of that ITU paper...ADPCM can use 2, 3, 4 or 5 bits per sample instead of the original 8 bits, and it was originally intended to be used with sample rate of 8 kHz, thus the bitrates 16-40 kbits. You can use it with other samplerates too.
With 8 bits you have quite limited dynamic range, so normalizing should be used to make most out of it.
QUOTE(itv @ Apr 27 2006, 03:10 PM)
QUOTE(Lacoona @ Apr 27 2006, 03:15 AM)
I read some thing about ADPCM:
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
Yes you are
Please read some more than just the topic of that ITU paper...ADPCM can use 2, 3, 4 or 5 bits per sample instead of the original 8 bits, and it was originally intended to be used with sample rate of 8 kHz, thus the bitrates 16-40 kbits. You can use it with other samplerates too.
With 8 bits you have quite limited dynamic range, so normalizing should be used to make most out of it.
At the output, before the signal enters the amplifier and after the filters, I have a variable resistor, so I can adjust the volume manually. Besides that I have many wave samples that already have the maximum 0xFF value, so I can't use normalization on them.
Anyway, the main problem is to find the optimal algorithm concerning the decompression time. I can make compromises concerning the compression ratio. The wave sounds are not big, the 64-128k memory is enough for 8-16 seconds of uncompressed sound at 8kHz. If I obtain the double it would be fair. Without any complex instruction, the ADPCM seems the fastest decompressig algorithm.
QUOTE(kjoonlee @ Apr 27 2006, 12:21 PM)
QUOTE(Lacoona @ Apr 27 2006, 06:15 PM)
I read some thing about ADPCM:
G.726 : 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
I have sounds with 32, 64, 96, 128 kbit/s (4,8,12,16 kHz sounds, 8 bits/sample).
Why would a normalizing help me?
According to the line above, ADPCM is not good enough for me.
Am I wrong?
You have 8bit PCM. You want to compress it, and you want it to be simple. Am I correct?
4bit ADPCM will offer 50% decrease in size with almost zero overhead.
It seems that the 4bit ADPCM will be appropriate in my case. However for comparission purposes I am looking for another algorithm. I have read a few words about Differential (or Delta) pulse-code modulation (DPCM), which results in a 25% compression ratio, but probably it is faster than ADPCM. If anyone knows any link, test result, c code please inform me.
QUOTE(Lacoona @ Apr 28 2006, 08:10 AM)
It seems that the 4bit ADPCM will be appropriate in my case. However for comparission purposes I am looking for another algorithm. I have read a few words about Differential (or Delta) pulse-code modulation (DPCM), which results in a 25% compression ratio, but probably it is faster than ADPCM. If anyone knows any link, test result, c code please inform me.
The topic of using some kind of audio data compression on machines that have little computing power is quite old. Here is an example from the days when most (home) computers had less resources than your average pocket calculator of today.
"8SVX" IFF 8-Bit Sampled Voice
This audio file standard was developed by Electronic Arts and Commodore-Amiga and got adopted in 1985. It specifies a compression scheme called "Fibonacci Delta compression" that stores 4-bit delta values instead of the original 8-bit samples. (for details, see Appendix C at the end of the linked document)
wavepak (freeware tool for Amiga, C source included)
"wavepak" is a Fibonacci-Delta / Exponential-Delta encoder / decoder for IFF 8SVX samples. Both are efficient, but lossy, compression techniques: They are fast and achieve a guaranteed compression ratio of 50 %, but at the cost of some 'quantization' noise.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.