Has anyone heard about any wavelet-transform based audio codec?
I know two still-image codecs and one video codec, but have not heard about audio codecs yet. for some reason I believe that wavelet-transform will do a good job for audio. (in particullar, will introduce less pre-echo)
edit: typos
AdaptedWave
http://www.adaptedwave.com/ (http://www.adaptedwave.com/)
Unfortunately, the site is gone. There used to be lots of information there and some demo samples. Seems that they will return soon. (hopefully)
thanks.
but I wanted to see something working (to steal some ideas and compare achivements )
i would ROCK of wavelets could do the same to audio encoding that it did with still images.
The jpeg2000 is far superior to plain jpeg.
i would ROCK of wavelets could do the same to audio encoding that it did with still images.
The jpeg2000 is far superior to plain jpeg.
Do you have any links to any tests done, JPEG VS JPEG2?
I also think that new methods for achieving transparent lossy audio coding are not necessary just gifted engineers for very fine-tuning.
I've seen some examples of Jpeg2000 vs normal JPEG, and beside some extra features like transparancy etc, imho the quallity of the format isnt much better. But it depends on your taste. Its like an Ogg-Vorbis vs MusePack tradeoff: the artifacts Jpeg2000 creates at lower quallity are less severe, but at higher quallity imho normal jpeg rules.
just my 2 cents, altough not really on topic ;-)
about that topic, should efforts indeed not be put on the current encoders, instead of new ones? exept when they are really superior...
JPEG2000 is not really more efficent than JPEG/JFIF for low compression (if you want image without visual artifacts).
But for highly compressed pictures, jpeg2000 is better than old jpeg. So it is depending on what you are targetting.
A drawback of jpeg2000 is the arithmetic coding.
A drawback of jpeg2000 is the arithmetic coding.
why is this a drawback? doesn't it work fast enough on most modern hardware?
Arithmetic coding rocks ! I wonder why the lamers over at Intel haven't yet introduced 1-2 new instructions to speed it up ?
Because it is quite hard to implement, it is strongly patended (holders agreed to give free licensing for use in jpeg2000), and it is quite slow (problem for embedded devices running on dsp).
But regarding compression, it is a powerfull tool.
It takes only some thought, a few hours and 30-50 lines of code to implement your own form of bitwise arithmetic coding.
With bitwise coding, and a given predictor, you can encode any data in the (asymptotically) optimal way..
Arithmetic coding cannot be patented, only some of its implementations can. If someone tried to patent the concept, then the patent is not valid.
Yes, too bad it's a bit slow.. but with the current machines, I don't think that's a big deal anymore (except for video probably).
there are patent-free opensource implementations. like this (http://www.google.com/search?q=Carryless+Rangecoder).
and it seems that speed won't be an issue at the time when jpeg2000 will be widely adpoted
Actually, the great issue about speed concerns the predictor, not the coder itself.
Patents have to include both predictor and coder, thus with your own predictor, you should be safe.
Here's a fixed version of the link from X-Fixer: http://datacompression.info/ArithmeticCoding.shtml (http://datacompression.info/ArithmeticCoding.shtml)
Here's a fixed version of the link from X-Fixer: http://datacompression.info/ArithmeticCoding.shtml (http://datacompression.info/ArithmeticCoding.shtml)
this one is good, too
I do not think that you can implement a jpeg2000 encoder without falling into IBM patents. The fact that some implementation are free of use regarding the code copyright does not change anything regarding the patents.
(but IBM has agreed to offer free license agreement for use in compliant products).
Speed is still a problem for embedded devices, as is something needs more processing power to be done, it means reduced battery life.
But I think that we are really getting off-topic.
I think Intel's Indeo audio codec is wavelet-based.
Intel being Intel, there are probably a few dozen Indeo technical spec sheets and white papers buried deep in the bowels of their humongous web site.
Yes, range coding comes very close to arithmetic coding in compression, is much faster, and is believed to be patent free. There are some papers and code here (http://www.arturocampos.com/ac_range.html) and here (http://www.compressconsult.com/rangecoder/) (this is actually the implementation that is used in Monkey's Audio).
Josh
i would ROCK of wavelets could do the same to audio encoding that it did with still images.
The jpeg2000 is far superior to plain jpeg.
Do you have any links to any tests done, JPEG VS JPEG2?
I also think that new methods for achieving transparent lossy audio coding are not necessary just gifted engineers for very fine-tuning.
sorry no link for a REAL objective test.
but i have test myself. but onyl with hi-res pcitures (1400x1400)
i i hav teste with 11 cd covers i have scanned by the following way
Scan in 600dpi (hardware)
cut it to 2800x2800
lite blurre effekte (to remove scale effect)
resample to 1400x1400
save as jpeg/jpeg2k at around 350kbytes
jp2k gives visual MUCH better quality here.
i did it in PSP 7.04
I think Intel's Indeo audio codec is wavelet-based.
Intel being Intel, there are probably a few dozen Indeo technical spec sheets and white papers buried deep in the bowels of their humongous web site.
Intel sold all their audio and video codecs to Ligos.
http://www.ligos.com/indeo.htm (http://www.ligos.com/indeo.htm)
You won't find any info on Indeo at Intel's site, except links to Ligos' site.
And I believe you won't find any techinfo at Ligos' site either.
Regards;
Roberto.
Yes, range coding comes very close to arithmetic coding in compression, is much faster, and is believed to be patent free. There are some papers and code here (http://www.arturocampos.com/ac_range.html) and here (http://www.compressconsult.com/rangecoder/) (this is actually the implementation that is used in Monkey's Audio).
yes, that's what I've actually meant. rangecoding is also used in La (I believe), PPMd (used in WinRAR and 7-Zip also) and (almost?) any other PPM or BWT archiver (e.g. bzip).
also, I've tested LureWave codec a while ago (not exactly a jpeg2k, but they are doing a jpeg2k codec now afaik). it gave a lossless compression somewhat worse than PNG, but lossy mode was really better than JPEG (for same filesizes on good quality) and the artifacts were less annoying ("loss of details" instead of "blockness" and "Gibbs effect").
if anyone is interested in real comparasion (and ready to provide test data) I guess I still can do it. though, real jpeg2k test would be more interesting
back on topic: I don't believe that Indeo uses wavelets, because it's rather old and generally... sucks.
Nothing really beats PNG in lossless RGB encoding og RGB pictures
There are not many other formats supporting more then 32bits color. or 8 bit alpha channels.
and the compression factor is the best for lossless.
Nothing really beats PNG in lossless RGB encoding og RGB pictures
There are not many other formats supporting more then 32bits color. or 8 bit alpha channels.
and the compression factor is the best for lossless.
WebP does beat PNG as it's straight outta '90s so as its homepage. PNG uses zlib to compress which is very old. WebP uses more advanced techniques for compressing losslessly, it also beats JPEG in lossy compression (tech used for lossy compression is similar to the VP8 codec).
https://developers.google.com/speed/webp/docs/compression (https://developers.google.com/speed/webp/docs/compression#lossless_webp)
well it was more than 15 years since that comment, so...
Yeah, and if you use a better PNG encoder, it a file will be a bit smaller (still lossless).
BTW, JPEG XL (https://jpeg.org/jpegxl/) is coming. And it seems very promising. It has lossless mode also.
(by the way, that part of that message which says that WebP beats JPEG in lossy mode is also incorrect, because lossy WebP is only possible to use with chroma subsampling, and with many images this never allows it to achieve visually lossless result at ANY quality parameter, while JPEG can scale to nearly lossless if you let it use enough bits)
HEI(F|C), WebP, AVIF and now JPEG XL. My guess is, we will continue to use JPEG.
There is also JPEG-LS for lossless, which usually beats PNG in efficiency and encoding speed and is only about 2x as slow for decoding. But the plugins for this format lack essential options (tagging dpi, best channel decorrelation, error recovery, etc.) and do not support transparency. When comparing formats with transparency, I would check that fully transparent pixels are encoded or not in all samples. One do either depending on needs. But if masked pixels get discarded or premultiplied, the file is not stricltly lossless then.
HEI(F|C), WebP, AVIF and now JPEG XL. My guess is, we will continue to use JPEG.
Webp saw some use since Chrome/FF/Edge supports it (even if it wasn't much better than JPEG and arguably kind of pointless). With avif there will hopefully be some more use, since its a better format and now Apple/MS are backing AV1.
Yes, and the BPG format makes chroma subsampling less painful, by using a downsampling algorithm on creation, and upsampling algorithm on decode. It will still look bad where there are conflicting colors, but there won't be any blockiness to the red contrasts, for instance. Whether you get this with JPEG or not is entirely dependent on which JPEG decoder you use.
JPEG allows using full resolution chroma, completely avoiding the issue
JPEG allows using full resolution chroma, completely avoiding the issue
Full resolution chroma isn't the most useful thing for the kinds of images these formats are aimed at (e.g. photo images), seeing as photographs are recorded on sensors with subsampled chroma anyway.
I must admit I don't get the math completely 100% but I had encountered photos in practice which don't reproduce faithfully with chroma subsampling (obvious differences) even at 1:1 size. And images are sometimes downscaled before compressing, then the difference will be even larger.
Red sections (fireworks (https://flif.info/lossy-artifacts.html)) of an image show noticeable differences on a regular density screen if the picture didn't lack sharpness in the first place. Without a direct comparison the color loss is not usually objectionable because soft photographs with a "video look" are common. The YCbCr transformation is fast and simple compared to Lab or the JPEG XL transform, and doesn't fully separate brightness from color (a red image still has brightness but most of it is in the chroma). The color bleeding increases with generation loss if the chroma is interpolated.
The fireworks sample image compresses to 1,354,422 bytes in JPEG-LS vs 1,686,570 in PNG.
Red sections (fireworks (https://flif.info/lossy-artifacts.html)) of an image show noticeable differences on a regular density screen if the picture didn't lack sharpness in the first place.
FWIW, even at 200% zoom and rapidly flipping between the subsampled webp and lossless PNG I don't see any difference in the red areas. As I understand it, the WebP uses 4:2:0.
Sure there are many cases where chroma subsampling is a great bit saver, but there's also a lot of cases where it is a deal breaker. A format which doesn't have full res chroma option, doesn't even stand in vicinity to "a holy grail of formats".
A format which doesn't have full res chroma option, doesn't even stand in vicinity to "a holy grail of formats".
Newer formats do have full resolution chroma. The comments above are about webp, which is ten years old and being phased out.
It didn't even catch up and is being phased out... 10 years is not much for a format, seeing how JPEG is "the format" for almost 25 years, and how even GIF is getting more popular (unfortunately) among the kids.
I somehow agree with tehabe that like MP3, JPEG is here to stay (unfortunately, again). Unless some serious steps will be taken to phase it out like it was with Java in browsers or Flash.
There's huge bandwidth pressure for video codecs, that's why they do get successfully replaced twice a decade. For pics and audio, gains don't seem to be huge enough for people to change habits.
I do not understand why a format should be phased out? If I have music in mp3 or photos in jpeg, then I want to be able to enjoy them. Not the old formats has to be phased out, but we need less new formats. We want people being more conservative. I for example keep using jpeg and I hope many of the formats mentioned here will not get following, and die out. Esp. webp, which I did not read a lot of good things about. In fact it seems Google are unable to follow the necessary rigor when it comes to standardization.
Make no mistake, I would like a good still image lossy format, and maybe JPEG XL looks to be one, but I will not encode into anything new until it is proven.
Make no mistake, I would like a good still image lossy format, and maybe JPEG XL looks to be one, but I will not encode into anything new until it is proven.
These are primarily formats used for distribution of content over the web, so you're not expected to be encoding things into them, and most likely JPEG will continue to be used indefinitely by individuals. Rather, with formats like WebP and onwards, websites notice that you are using a modern browser and silently use newer formats to save bandwidth.
WebP does beat PNG as it's straight outta '90s so as its homepage. PNG uses zlib to compress which is very old. WebP uses more advanced techniques for compressing losslessly, it also beats JPEG in lossy compression (tech used for lossy compression is similar to the VP8 codec).
https://developers.google.com/speed/webp/docs/compression (https://developers.google.com/speed/webp/docs/compression#lossless_webp)
Well, PNG has great tool support and some advances in deflate-compression also happened. Find enclosed:
- Your PNG, optimized with zopflipng (lossless)
- Your PNG, quantized with pngquant, then optimized with zopflipng (lossy, but nicely compact)
Does not change the fact that one could engineer formats with, e.g., better entropy coding. Too bad many PNG compressors seem mediocre and the possibility of producing "lossy" PNGs does not seem to be generally known.
edit: Oh, didn't notice that VEG already posted an even better optimized lossless version. I wonder what compressor was used...
Nice, all those pictures. The question was "Wavelet-transform based audio codec". Is there a fundamental problem using wavelets for audio or is it a development problem for AUDIO? If it looks nice, it does not mean it could sound nice.
It got sidetracked in 2003 already :))
Nice, all those pictures. The question was "Wavelet-transform based audio codec". Is there a fundamental problem using wavelets for audio or is it a development problem for AUDIO? If it looks nice, it does not mean it could sound nice.
There was some discussion of this back in the early 2000s, I forget the details but I think the conclusion was that there wasn't an advantage over a more conventional MDCT codec with variable block sizes.
FWIW, there have been codecs (WMA) that allowed many different transform sizes to be overlapped in the file so that the time/frequency tradeoff could be almost continuously adjusted. They were not spectacular, so I suspect that there just isn't much advantage to be gained from more flexible time/frequency transforms.