Because supporting lossless audio streaming is as useful as supporting TIFF images or UTF-32 text encoding. Nice to add to the spec sheet; mostly useless in a practical setting.
The only purpose that comes to mind for delivering lossless audio within a web page is to build, somewhat ironically, a lossy codec comparison tool which would in turn demonstrate why lossless audio isn't necessary.
As an audio engineer, I must point out what is wrong with this statement.
Sure, the average listener cannot discern between FLAC and a well-encoded lossy audio file. However, with the Web Audio API making big advancements, the need for in-browser FLAC support is becoming quite apparent.
People are building all sorts of web apps for creating, manipulating, and processing audio. For this use case, working with lossy audio is out of the question. Supporting FLAC means the ability to follow signal flow best practices [0] without requiring the user to work with much larger PCM files.
I'd love to have a wide-supported float32 format with reasonable lossless (and maybe lossy) compression options.
Conversely, FLAC supports different resolutions and sampling rates, so it does do the job for the sound processing.
[0]: https://github.com/onli/music-streamer, but there are probably better alternatives
The discussion in the bug itself covers JS flac implementations https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2
There doesn't seem to be any testing around security, attack surface, etc. Disappointing, and not recommending that anyone use Firefox for the foreseeable future.
That's silly. By that argument no browser should ever bother adding any new features.
Browsers should add features where only they have access.
That's not clearly bad - the range of obscure formats is long & it's easier to update an app than every client - but it is a cost.
I'm still waiting for the day when the OPUS codec is supported everywhere.
OPUS is some serious next-gen shit: https://www.opus-codec.org/
So there is at least one of us who has a serious need for flac in a browser. And the bandwidth it uses is still less than with a typical full-hd video stream.
Links? "subjectively indistinguishable" would be a bit less argumentative
More here: https://www.opus-codec.org/comparison and all over https://hydrogenaud.io
Blind testing is also easy to do yourself.
There is no price difference when buying mp3 or flac and storage + bandwidth is cheap nowadays. If I need a lossy compression, I want to have a control on the compression parameters.
I promise you that you can't ABX the two.
And as I said in another branch in this discussion, mp3 + bluetooth compression is pretty awful already.
I keep all the music I own in FLAC as well, but have written scripts to transcode to Ogg Vorbis for portability.
Weirdly, this seems to be one of those tech things where it’s impossible to actually find out whether a bluetooth devices supports more than just the mandatory codecs & it’s equally impossible to find out whether your sound path is passing the source through or not. It’s all completely opaque.
Modern bluetooth devices can also negotiate various other codecs as part of the A2DP spec: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Adv... including mpeg3/mpeg4 encodings but only SBC is mandatory and it seems to be impossible to tell what codec any particular Bluetooth audio device is using on any platform: I’ve not seen anything that will tell you what it’s really sending over the air.
Wireshark can read bt_hcisnoop.log as a Symbian OS Bluetooth Log (really). From a bit of fiddling you're looking for a series of AVDTP requests with GetCapabilites (to your speakers/headset/whatever) and then SetConfiguration (from your phone/player). Filtering by btavdtp.service will get you this.
I can tell you my phone is ignoring SBC and AAC support and asking for APT-X only.
(And it should be made clear that I have no in-principle issue with anyone purchasing or storing their local music library in a lossless format. It's a valid decision, particularly if you're establishing your music library in the last 5-10 years.)
What I don't want to have is an automatic lossy compression done by systems which the artist has no influence. Depending on the sound of the original music, this might have no effect or then the compression completely ruins the dynamics and sound of the original production.
On this time and age, bandwidth is cheap and the connections are fast. Disk space is cheap and cloud storage is cheap. I don't see so many reasons to use lossy files anymore and with flac I can be sure that I have the closest possible copy of the production that left the artist's studio.
In the way they are commonly used, lossy compression codecs have zero impact on dynamics. Correctly used, lossy compression can have zero audible consequence no matter how good the equipment or how "golden" the ears.
That said, a recording studio shouldn't ever be dealing with lossy codecs, because there's simply no need to, and because there's a sliver of possibility that the inaudible lossy artefacts could compound into an audible artefact over multiple generations.
The only time a lossy codec should ever be used is by distribution networks and/or end users.
That's why the compression should be done by me or by the original producer to have it done correctly case by case. Lossless is a good compromise it being easier to apply automatically for any kind of music.
For streaming audio, the ideal setting might be different depending on the commercial priorities of the service.
For audiobooks, convenient file sizes will probably be higher priority than maximal compression transparency.
For multichannel audio, you would need to progressively increase the bitrate on a per channel basis.
Agree with all your other points, and glad to see others that grok it.
I don't want artists or producers having any say in audio encoding formats – because the audio encoding format should be transparent and therefore have zero impact on the actual artwork.
Who cares what uses it has? It's a whole new area of capability. Somebody could find a new use for it. If we limit our choices based what's currently possible, we get nowhere.
You never know how a piece of audio might be used, and once you've thrown away information you can't get it back.
In a past life I was an audio engineer, and I spent hours tirelessly testing mixes on every kind of system. You are the listener I was working for.
Your reasoning seems to be "only deluded, pedantic audiophiles want lossless, and audiophiles don't listen though matrix decoders". But that begs the question - the whole point of relating my personal experience was to show how a perfectly reasonable and commonplace listening style could benefit from lossless encoding.
I completely accept that matrix decoding is a legitimate way to listen to music. I do it myself on occasion. But even before you throw lossy compression into play, it's worth acknowledging that Pro Logic decoding of a non-Pro Logic signal is hit-and-miss at best, which can often trip up or be generally unpleasant with many types of material.
> The standard allows indexed color PNGs to have 1, 2, 4 or 8 bits per pixel; grayscale images with no alpha channel may have 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16.
https://en.wikipedia.org/wiki/Portable_Network_Graphics#Pixe...
> TIFF is a flexible, adaptable file format for handling images and data within a single file, by including the header tags (size, definition, image-data arrangement, applied image compression) defining the image's geometry. A TIFF file, for example, can be a container holding JPEG (lossy) and PackBits (lossless) compressed images. A TIFF file also can include a vector-based clipping path (outlines, croppings, image frames).
Likewise, not many viewers (and certainly no browsers) support everything in the PNG standard. If you expect more than a simple compressor for some pixels, you're basically SoL when it comes to browsers.
This has come to nip myself (and others) when doing screenshots for old games such as Doom, where the pixel aspect ratio is not identical to the way they were displayed. It would be nice if we could just set the flag in PNG to tell it the display aspect ratio is 4:3, but literally no browsers support that flag. Instead we have to depend on lossy scaling so the pixel aspect ratio is identical to the display one.