Skip to main content
Topic: Wavelet-transform based audio codec (Read 5340 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Wavelet-transform based audio codec

Reply #25
HEI(F|C), WebP, AVIF and now JPEG XL. My guess is, we will continue to use JPEG.

Re: Wavelet-transform based audio codec

Reply #26
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.

Re: Wavelet-transform based audio codec

Reply #27
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. 

Re: Wavelet-transform based audio codec

Reply #28
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.

Re: Wavelet-transform based audio codec

Reply #29
JPEG allows using full resolution chroma, completely avoiding the issue
some ANC'd headphones + AutoEq-based impulse + Meier Crossfeed (30%)

Re: Wavelet-transform based audio codec

Reply #30
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.

Re: Wavelet-transform based audio codec

Reply #31
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.
some ANC'd headphones + AutoEq-based impulse + Meier Crossfeed (30%)

Re: Wavelet-transform based audio codec

Reply #32
Red sections (fireworks) 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.

Re: Wavelet-transform based audio codec

Reply #33
Red sections (fireworks) 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. 

Re: Wavelet-transform based audio codec

Reply #34
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".

Re: Wavelet-transform based audio codec

Reply #35
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.

Re: Wavelet-transform based audio codec

Reply #36
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.

Re: Wavelet-transform based audio codec

Reply #37
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.

Re: Wavelet-transform based audio codec

Reply #38
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.

Re: Wavelet-transform based audio codec

Reply #39
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

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...

Re: Wavelet-transform based audio codec

Reply #40
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.

Re: Wavelet-transform based audio codec

Reply #41
It got sidetracked in 2003 already  :))

Re: Wavelet-transform based audio codec

Reply #42
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. 

 
SimplePortal 1.0.0 RC1 © 2008-2020