Perfect Clarity

What does anyone make of this:

http://www.harmony-central.com/Newp/2000/Perfect-Clarity-Audio.html

The compresion ratio didn't look all that good. It probably also depends on floating point to decode it-unfortunately the empeg has no fpu.

Sean

Empeg 12 gig green 080000078

Sounds good - but not really for the empeg.. Sonic's been known for their high-quality audio editors - but wav files can be very large; this is loss-less but smaller; good for editing/mastering purposes, but not really for storing...
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

It probably also depends on floating point to decode it-unfortunately the empeg has no fpu.

My guess would be it doesn't, if it really produces output identical to the input. Floating point is not something you can expect bit-for-bit exact results from.

Borislav

I'd be willing to sacrafise 1/2 the disk space for non-loss compression formats.. maybe the empeg guys would add support in 1.1 for gziped wav files. .. emplode could scan the wav file, gzip it, make the proper database entries for track length.. maybe it could be similar to linuxcare's block-compressed system.. break it into 16k blocks, gzip each block, and stick a header at the begining to tell it where all the chuncks are. (for random play)

I have specific tracks that just don't compress well.. even when i turn on 192-256k high quality..


12gig green mk2 -- 080000125

most likely, it's based on a gzip like format, tuned for audio. (like bzi p is tuned for text) I've looked into some more open-standard non-loss compression types.. and there has been talk about adding the formats to the empeg.

floating point isn't really necessary, most of the operations are bitwise, so they don't loose data.. floating point operations loose data. (famous bug note.. pentium FDIV bug was 10th decimal error, enough of a loss to make it a problem)

and like the empeg guys have proved.. anything you can do in FPU, you can do in INT..
remember, doom2 was all INT, no FPU (and wow, what a game :)

12gig green mk2 -- 080000125

Errmm - the higher the quality (192-256k) the lower the compression rate. VBR would be the best relation between compression rate and quality.

maybe the empeg guys would add support in 1.1 for gziped wav files
You would have to leave enough free space on the disk to unzip the files and in my opinion this would be a waste. But that would be a thing everybody could decide for him/herself

TeeMcBee
Got my Mk2! # 080000143

In reply to:

---

You would have to leave enough free space on the disk to unzip the files and in my opinion this would be a waste.

---

Not so - gzip is a relatively simple task and if you're decompressing straight into memory, or in this case a DAC, then it takes up much less processor time (which goes into writing file system structures and so forth). You can use it as a pipe. I've had plenty of times where I've used gzip | grep | more and it works faster than I can scroll the text even on .1% hits.

Besides, gzip is not good for compressing files of words larger than 8 bits - there's too much related information between the two bytes in a 16-bit word for gzip to get good compression. I'm working on an open lossless compressed audio format that encodes the left and right channels separately and uses 16-bit words rather than 8-bit. I have no code for it yet but stay tuned.

As soon as I get my hands on a copy of Delphi...

Save the whales. Feed the hungry. Free the mallocs.

excelent, this is exactly what I was thinking.. gzip was just a simple compression system, first thing that came to mind.. but i've looked around, and there are several proprietary formats for audio-optimized lossless compression.. an open standard would do the world a lot of good.. if i were a better coder, i would work on it. but i'm just a sysadmin :)

12gig green mk2 -- 080000125