Hacker News Reader

Comment by niftich | Hacker News Reader

Finally!

I wonder why this took so long. The assumption that no sane site would want to stream in lossless when lossy codecs were starting to be really good (and obviously much smaller)? Lack of expertise, manpower? Priorities? [1][2] Does every FF feature has to be 'parity-chrome'?

It's even more interesting that Chrome also sat on this for ~5 years [3] and are just now about to release it also.

Like the Firefox thread insinuates, will pundits credit TIDAL for lighting the fire under browser vendors to support lossless streaming? No such link appears to exist, aside from TIDAL already streaming to Chrome using NaCl [4], but when we look back in 10 years and see both of the major browser vendors adding FLAC support now as opposed to any other time in the previous 5 years, what will people think?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=514365 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=586568 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=93887 [4] https://support.tidal.com/hc/en-us/articles/202654692-HiFi-O...

View on HN

> I wonder why this took so long.

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.

so according to you leaving a castle fall into ruins is "good enough" because nobody wants to see it...

That would appear to be overwhelmingly the consensus of people with castles, too. Do they have some moral imperative to pay maintenance forever on something that has no use value and no hope of paying for itself?

I have pretty decent headphone system at work. I'm constantly using services like Tidal HiFi and listening to my own flac collection from Style Jukebox. I just want to have my music in the original quality and if needed, transcoding down to mp3.

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.

Why not stream in ~256kbps AAC or Opus? The audible quality drop is objectively proven to be zero. Make peace with the placebo effect and enjoy your life.

> objectively proven

Links? "subjectively indistinguishable" would be a bit less argumentative

http://listening-test.coresv.net/results.htm

More here: https://www.opus-codec.org/comparison and all over https://hydrogenaud.io

Blind testing is also easy to do yourself.

AAC is mostly Apple-stuff and I'm out of those pictures. Where do you have a music streaming platform that serves Opus? Flac is the best trade-off. I get the original quality, I can store my files to a cloud service and stream the music without using too much bandwidth (it's 2016 anyways). I have seriously good headphone system at work (for the price of a new iPhone) and at least with Style Jukebox I can switch between 320 kbps mp3 and the original flac where I definitely see a difference.

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.

AAC is part of the MPEG-2 and MPEG-4 standard. You probably listen to AAC-encoded audio far more often than you realise.

But not really with any of the music I buy...

All web browsers support the downloading of FLAC files.

If you can tell a difference between 320 kbps mp3 and FLAC, then your mp3 encoder has a bug.

I promise you that you can't ABX the two.

Mp3 is really useful if I transcode and stream some music while having data caps. But do I really have any valid reasons to archive the music I own with a lossy codec?

And as I said in another branch in this discussion, mp3 + bluetooth compression is pretty awful already.

If you care so much about music fidelity and are using bluetooth, then I'm inclined to say you deserve what you get.

I keep all the music I own in FLAC as well, but have written scripts to transcode to Ogg Vorbis for portability.

Oh, I forgot one big deal: Bluetooth audio. I use bluetooth headphones when commuting and I have a Bluetooth receiver at home for convenience. Here it's a big deal if you compress with a lossy compression two times: once to MP3 and again when using Bluetooth. The loss in quality is significant.

Decent bluetooth receivers can decode mp3 / mp4 & a correctly setup sound path should pass the mp3 packets straight from source to speaker without a decode/encode stage.

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.

I really need a technology like Bluetooth, but there seems to be no other that works with all devices. Bluetooth audio is a black box and you never can't be sure what happens between the device and receiver.

Are you talking about apt-x?

APT-X is a proprietary codec that performs far better than the original bluetooth audio codec & can be used for things that said codec really was’t up to. (It also includes a lossless mode for the audio purists amongst us.)

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.

I have never seen a subjective comparison where Apt-X beats SBC. It seems to bee all marketing hype.

If you're able to test with an Android device running 4.4 or later, you should be able to turn on Bluetooth Logging in Developer Options.

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.

That is impressively convoluted. I have a feeling it ought to be possible to write a gstreamer plugin to do this, but it’s one of those minor projects that never got over the do-I-care-that-much hump.

I've got a feeling that by the time an audio stream gets to GStreamer it's not in the original format. Also you'd have to get an A2DP sink working (to make your phone think the computer is a headset / speaker)

You shouldn't be using bluetooth headphones with lossy compression if you care about audio quality.

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

So to summarize my thoughts (had a nice cup of coffee and thinking, Sunday anyways), the people I allow to do compression for the music I buy is the artist/producer herself or me. I really don't like having a third party in the middle turning the knobs for the music I buy.

You are of course aware that what you are listening has already been tweaked, knob-turned and filtered by the recording studio, sound engineers, artists and whoever else was involved. In the end music is subjective. It sounds different and pretty much every playback system. And to the listener, it either sounds good or not. It's never "correct".

Of course. The typical music I listen to (techno mainly) goes through the producer's studio and usually has another person doing the mastering. Until now all compression is done by professionals who have ear how the end product should sound (with their Genelec studio monitors, of course). I'm fine with this.

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.

Yes, you are definitely conflating dynamic range compression (dynamics) and data compression (codecs). These are very different, completely unrelated issues that unfortunately bear the same linguistic shorthand of "compression".

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.

> Correctly used, lossy compression can have zero audible consequence no matter how good the equipment or how "golden" the ears.

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.

Correctly used just means not using stupid settings like 96 kbps MP3. Apple's standard of 256 kbps AAC is correct in all cases.

But this still doesn't solve the original issue: if I buy music, it should be me who packs the files if I need to lose some information and I should own the original copies lossless. And as I also said, bandwidth and storage space are super cheap nowadays, so I really don't see so many reasons to use lossy codecs.

If you "buy" music to "own" you are downloading a file, not streaming it live through a web browser which is the topic of this HN discussion.

I store my music to cloud and stream it from there. So yes, I stream flacs anyways :)

For some definitions of "all" I agree. i.e. for Hifi quality Stereo Music to end users where file size and bandwidth are not so important, yes fine, but in situations where space or bandwidth are limited / expensive, AAC can achieve transparency at well below 256kbps with most music, to most people, in which case it would often be overkill --especially for Audio Books, lectures, plays or other mainly speech content... conversely for 5.1 or greater multi-channel audio it's often insufficient.

Sure, I was just talking about stereo music where audio quality is high priority.

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.

Yes of course, sorry -- I was kind of in 'reddit mode' and being particularly pedantic about "all cases".

Agree with all your other points, and glad to see others that grok it.

They don't have to be conflating those things. For example are you sure Youtube doesn't apply dynamic processing to uploaded files? I wouldn't be surprised if there is some sound processing performed to help make the average phone video sound better.

Depends on the kind of music. If you're listening to the recording of an harpsichordist playing Scarlatti in a room, then you can measure the difference between what you hear through your speakers and what you would have heard if you were sitting five meters behind during the play. And then being more correct means having less difference.

When you refer to what an artist or producer is doing, you may be talking about a different kind of compression (dynamic range compression) than this topic covers (data compression).

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.

Why re-encode when there's no need?

The point isn't about audio quality. It's about having a free and open way to do it at all!

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.

Those listening tests are done on stereo headphones. I often listen to music through a 5.1 system, which processes the stereo signal through a Dolby Pro Logic II decoder in order to feed the 5 speakers. This stresses lossy codecs much more than listening through headphones; phase information is used for sound placement, and sounds that would normally be masked often end up sufficiently localised to discern (this is part of the fun of a surround system). I can definitely hear outright artefacts at rates and codecs purported to be transparent.

You never know how a piece of audio might be used, and once you've thrown away information you can't get it back.

Thank you.

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.

Sounds like I should be thanking you. I'm amazed at how good things often sound when treated that way - I'm glad that artistic input goes into it.

I agree in principle, however I disagree with the logic insofar as anyone who is listening to music through Pro Logic (or a similar matrix decoder) is by definition not a target audience for pedantic degrees of audio signal preservation.

Not really sure what you're trying to say. Why am I not allowed to be in the "target audience" for not wanting artefacts in my music?

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.

Please don't put words in my mouth. I would never say that you have to be deluded or pedantic or an audiophile in order to justify lossless audio file. And I would never ever say that "audiophiles don't listen though matrix decoders".

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.

Not necessarily. I use a site local to my network to play music in my browser using the audio tag [0]. Some of the music in my library is flac. I never came around encoding them, and the transcoding support of my player never worked perfectly, so much that I finally got annoyed and cut it. Having flac support in the browser will make those audio files work without further work on my side, which is great.

[0]: https://github.com/onli/music-streamer, but there are probably better alternatives

That's a reasonable counter-example. Thank you.

Lots of browsing activity occurs on the intranet where bandwidth is effectively infinite. But I am not sure why more native code is being added to firefox that handles file parsing. An emscripten based extension to firefox could have been just as effective. And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot.

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.

>And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot.

That's silly. By that argument no browser should ever bother adding any new features.

Not ones that are trivially added "in user land".

Browsers should add features where only they have access.

Shipping new Firefox code that parses untrusted data from the network normally requires security view, and a new fuzzer for the data format in question is usually written. There's lots of process and infrastructure around this sort of thing at Mozilla. This is sometimes handled in a separate bug from the one implementing the feature. I'm surprised that the corresponding security review bug isn't linked from the FLAX bug, though, which may be an oversight. (Or it may be the non-public blocking bug, and it's non-public because an issue was found.)

Now that I think of it, the majority of this work should have been done in JS land, with the heaviest decoding being exposed as a document._firefox.media.flac_decode() method that takes a buffer of flac stream. That one flac stream could be formally verified, everything else lives in user land.

We have the exact same use-case for TIFF or JPEG 2000: users can browse a giant repository. They can view many files directly but we have to run a transcode server for browser-unsupported formats, which also means things like the standard Save As UI no longer work as expected.

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.

If your source media is FLAC (which is a good way to store 'source' material, that you might lossy-encode later) then being able to just stream that without any encoding step is handy. Maybe you wouldn't do this if you were concerned about bandwidth, but I'd certainly welcome this in a player to use on my LAN.

> Nice to add to the spec sheet; mostly useless in a practical setting.

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/

Why the comparison to TIFF ? If you want to insist in that analogy, are you aware of PNG and UTF-8 ?

That's the point. The point of the analogy is precisely that there are existing formats that are capable of the same practical quality with much smaller file sizes. PNG is smaller than uncompressed TIFF. UTF-8 is much smaller than UTF-32.

HugoDaniel was referring to the fact that PNG is lossless as well. The rest of your point still stands, of course.

I got your point but just FYI, TIFF supports 16bit per channel images. PNG and JPG do not. I think TIFF might also support floating point images. Those might be useful for raw manipulation and HDR. Safari supports TIFF BTW (or did last time I checked). No idea if there is a way to get access to the high res data in Safari though.

Actually, PNG supports 16 bit channels (as well as 1, 2 and 4 bits for paletted or greyscale images). TIFF meanwhile is kind of a kitchen-sink container format, so you can do quite a bit of strange things with it (store JPGs inside it, support tiling), but I don't think many viewers support everything in the TIFF standard.

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

https://en.wikipedia.org/wiki/TIFF#Features_and_options

> Actually, PNG supports 16 bit channels (as well as 1, 2 and 4 bits for paletted or greyscale images). TIFF meanwhile is kind of a kitchen-sink container format, so you can do quite a bit of strange things with it (store JPGs inside it, support tiling), but I don't think many viewers support everything in the TIFF standard.

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.

Couldn't you nearest-neighbour upscale in a 4:3 ratio beforehand?

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

[0] https://en.wikipedia.org/wiki/Audio_signal_flow

I think this is the most reasonable argument for supporting FLAC natively. We have support for lossless images in the browser already - TIFF isn't the image analogue, but rather PNG.

Except that PNG is by far not sufficient in professional image manipulation: it's compression scheme is good and 8uc{3,4} is lossless, but beyond 8bpc you're out of luck.

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.

This isn't just academic. As OP pointed out TIDAL is not only using lossless but touting that as a key selling point.

Why this takes so long is because once such a standard is introduced, you can't take that decision back anymore without breaking a lot of things. They don't want to introduce standards which end up being used only by a small number of people while causing a lot of maintenance-work and then being tied to maintaining it anyways.

That also is the reason why these decisions often happen in the same time frame for different browser vendors. If another browser vendors decides to introduce it, you can be much more sure that you won't be supporting it without anyone using it. And obviously also just to not be left behind by web developers.

Maybe so. The counterpoint is that several of APIs added to the web platform in the last ~8 years have already been deprecated: stuff like WebSQL, File System, AppCache; there is no shortage of moving fast and breaking things when it comes to browser vendors.

Something like a codec is comparatively trivial, because as a content server you can never rely on everyone supporting the same codec, so you have to stream among multiple formats anyway. When all of these JS APIs that FF or Chrome added were later deprecated and removed, everyone had to re-code their sites. So I'm hesitant to accept 'let's be really careful about this' as a rationale here.

> The counterpoint is that several of APIs added to the web platform in the last ~8 years have already been deprecated: stuff like WebSQL, File System, AppCache

And two of these have been replaced by complex, over engineered stuff. WebSQL was replaced by IndexedDB which can't do a simple equivalent of SELECT ... ORDER BY ... GROUP BY... without ending in callback hell, and AppCache was replaced by ServiceWorkers.

I've seen more animated PNG than FLAC files. Animated PNG got removed from Firefox.

No it didn't.

You're thinking of "MNG", which is a different PNG-related animation format than the simpler "animated PNG". MNG was removed, but animated PNG is still supported in Firefox and indeed is used in its UI.

I stand corrected.

> Does every FF feature has to be 'parity-chrome'?

No, this is "parity-web". Web browsers usually simultaneously decide to implement or enable features. Firefox isn't copying Chrome; they're implementing the same feature at roughly the same time (presumably after discussing it first), so as not to cause further web compatibility rifts.

Reply on news.ycombinator.com