api.HTMLAudioElement - Not all audio formats supported

[DusteDdk]

What information was incorrect, unhelpful, or incomplete?

Incomplete: The Audio() element does not fully support the filetypes indicated in the documentation. It is documented that FLAC is supported, however, FLAC files with a large ID3 tag does not work as expected.

What did you expect to see?

I expect it to say partial support. I expect that if I point the address bar to a file, and it plays, then the Audio() class will be able to decode that file if I set its src property to the URL of that file.

Did you test this? If so, how?

1. Point the addressbar to a FLAC file with an ID3 header. Verify that it plays as expected, stop it.
2. Press F12, in the js console type: (new Audio()).src='path/to/file.flac'; and press enter, a decode error. Even though content-type from server is correct AND the url has the .flac extention, the Audio element ignores these, tries to guess, and fails to decode the FLAC file as MP3.

MDN page report details

• Query: api.HTMLAudioElement
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/HTMLAudioElement
• Report started: 2021-09-14T19:26:39.334Z

[ktmf01]

ID3 support is not part of the FLAC spec. In fact, it is discouraged.

Therefore, I would consider this not 'partial support'. The FLAC format is fully supported, as ID3 is not part of the spec.

[DusteDdk]

Therefore, I would consider this not 'partial support'. The FLAC format is fully supported, as ID3 is not part of the spec.

Yeah, the reality, though, is that flac files like that, which play just fine (tm) in all players (including firefox) are not uncommon, they're out there on the Internet, it's not like I created a bunch just to annoy people and complain, I literally hit my head on this multiple times when browsing music.

Your "technically correct" conclusion conveniently ignores reality. In much the same way that the browser in question ignores the HTTP CONTENT-TYPE HEADER!!!! in lieu of trying to ducktype the datastream with some third-party library (which is a reasonable fallback in case there is no CONTENT-TYPE, but is an exceptionally retarded default thing to do when the header is available).

[ktmf01]

Your "technically correct" conclusion conveniently ignores reality. In much the same way that the browser in question ignores the HTTP CONTENT-TYPE HEADER!!!! in lieu of trying to ducktype the datastream with some third-party library (which is a reasonable fallback in case there is no CONTENT-TYPE, but is an exceptionally retarded default thing to do when the header is available).

Are you sure it does that? It could very well be it tries to parse the file as FLAC first and fails, because the FLAC format specifies the first 4 bytes of a stream or file must be fLaC. If a ID3v2 tag is present, this is not the case and a decoder or parser could decide to not investigate any further as a FLAC file and ducktype instead. I wouldn't call that retarded in any way.

You are right that many decoders are able to skip over an ID3v2 tag. This might be because the FLAC format is designed in such a way that a decoder can start decoding at any point in a stream (this was done so FLAC can be multicast without problems). It could be some decoders simply ignore the ID3v2 tag not because they know it can be ignored but because they are programmed to look for the first FLAC frame they find, ignoring anything before that point.

Still, this technicality (not being able to parse a malformed FLAC stream) is not something I would consider necessary to claim full support.

[queengooborg]

Because browser vendors may implement support for individual media codecs as desired, a lack of support for an entire codec wouldn't be enough to mark the Audio() constructor as partially supported in BCD. We are considering a way to add data for media formats though, see #6971.

---

Regardless, I'm going to say that this is very much an edge case. I have not been able to set up a test case because all audio programs I've been using have been writing Vorbis tags to the FLAC file, not ID3v1 or ID3v2 tags. This includes Adobe Audition, Audacity and even ffmpeg -- and if a low-level program like ffmpeg isn't letting me do so, I feel confident in saying that any FLAC files that do have ID3 tags are malformed.

[DusteDdk]

The problem here is that the browser ignoring the http content type which correctly identifies the file and allows it to be played , the player works fine with the files, such as when clicking the link to such a file.

man. 4. dec. 2023 09.55 skrev queengooborg @.***>:

Because browser vendors may implement support for individual media codecs as desired, a lack of support for an entire codec wouldn't be enough to mark the Audio() constructor as partially supported in BCD. We are considering a way to add data for media formats though, see #6971 https://github.com/mdn/browser-compat-data/issues/6971.

Regardless, I'm going to say that this is very much an edge case. I have not been able to set up a test case because all audio programs I've been using have been writing Vorbis tags to the FLAC file, not ID3v1 or ID3v2 tags. This includes Adobe Audition, Audacity and even ffmpeg -- and if a low-level program like ffmpeg isn't letting me do so, I feel confident in saying that any FLAC files that do have ID3 tags are malformed.

— Reply to this email directly, view it on GitHub https://github.com/mdn/browser-compat-data/issues/12392#issuecomment-1838097259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIH22OL7VL4JPPYX7RENJLYHWFX7AVCNFSM5EA3L4ZKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTHAYDSNZSGU4Q . You are receiving this because you authored the thread.Message ID: @.***>

[queengooborg]

Well, here are my questions to you then:

• What browser are you using? (You had not mentioned which browser is affected.)
• Is this still an issue in the latest version of the browser?
• Have you found a corresponding bug report in the browser's bug tracker, or created one yourself?
• What is the source of the FLAC files you are testing with? Are they ones you downloaded or did you create them yourself?
• What happens if you use the standard way of defining an audio source on construction? new Audio('path/to/file.flac')
• If you are able to (AKA it doesn't violate copyright laws to share), would you mind providing one of the affected files so we may test it ourselves?