1170666 - ogg flac not recognized

Status: RESOLVED INVALID

(Core :: Audio/Video, defect)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Build ID: 20130910160258

Steps to reproduce:

so, i'm putting together an html front-end for a flac dvd of my own original music. all i want it to do is load a flac with html5. now, i know that this is not currently supported because the flac headers are complicated, but what seems to be less understood is that the flac encoder has a built in container that puts it into an ogg header using the --ogg switch. the problem is that i can't get the html5 audio tag to read the ogg container of the flac file - it tells me the "video" is corrupt. in fact, this is what the ogg flac workaround is meant to deal with, so if i can't find a local problem then i do believe that this is a bug.

steps:

1) create an ogg flac file out of a wave file using the flac.exe from xiph.org:
flac.exe filename.wave --ogg

(this creates filename.oga)

2) put this into the html file:
 a) <audio controls src='track01.oga' type='audio/ogg codecs="vorbis"'>  (i've tried multiple variations)
b) <a href ="track01.oga">click</A>


Actual results:

the audio controls do not appear at all, and the link goes to the "video cannot be played because it is corrupted" page, with the x over where the controls should be.


Expected results:

well, i'm under the impression that the ogg flac container was created for this specific purpose, so i think it should launch the controls. both options work for mp3s (but i'm selling lossless files, so i can't degrade the quality). what i'm trying to figure out is if this should actually work, or if firefox is correct in telling me the flac ogg is a corrupted ogg file - in which case this is a type of support i'd argue should exist, because it's an ogg container. i mean, this is the point of the ogg container workaround!

i'm also a little unclear as to whether this is a local issue. i know that something that often needs to be done is that the mime types need to be updated on the server side, but i don't have a server so i'm not sure if there's a parallel to try at home for local streaming and can't find the information anywhere....

i should also point out that i don't have media player installed on my windows 7 laptop. i would not expect this to be an issue. the oga files are properly decoded by foobar, so the actual --ogg switch seems to be doing what it's meant to. i'm just not sure if firefox can currently get through the container or not - but i'd argue it really should be able to.

Comment 1

[[e-mail]]

i should also point out that i've tested the controls with ogg files encoded with the xiph encoder and the controls work fine, so there's not a general ogg issue, locally. i'm leaning heavily towards firefox being unable to read the ogg flac container.

Comment 2

[Loic]

I don't know if you're really using FF24 but this version is completely outdated. If that's the case, could you update to 38.0.5 and test again, please.

In addition, provide a testcase with the video file that demonstrates the issue.

Comment 3

[[e-mail]]

i can try in a virtual machine, but there's ui reasons underlying my refusal to upgrade (i can't make ui choices i want in newer versions) and i honestly don't think it's anything to do with it. it's a basic html5 thing. i can stream oga files from servers. as mentioned, it's not a video file but an "ogg flac" - which is a flac audio file encoded in an ogg container. it seems to be expecting a vorbis file and telling me the flac is corrupted. but, it's not corrupt; rather, the whole point of encapsulating the flac in the ogg container is to get around that.

i've tried creating a new "audio/oga" mime type in the windows registry and sending the clsid to the flac decoders, but i get the same behaviour. in fact, i get the same behaviour if i rename the filew to "track01.xyz", which indicates that it's checking the header on the file and interpreting it as ogg *before* it checks for file associations, which strikes me as completely backwards. it really forces the issue as a coding problem without any other kind of workaround, unless there's a setting somewhere that lets me turn that off.

i'll try in a vm and get back in a few minutes, but i don't expect anything different.

Comment 4

[[e-mail]]

ok, actually, there's a media.ogg.enabled in the about:config. i turned that off, which let me set a mimetype - but it interpreted it as video. i think that's the bug - it's interpreting ogg flac as ogg video and not letting me override it. but i'll check the vm....

Comment 5

[Loic]

The video decoder has changed since FF24, and maybe the video file is bad encode, that's why we need a simple testcase with a shot video file.

Comment 6

[[e-mail]]

it's an audio file. i don't know exactly what you're asking for in terms of screen shots.

i was able to get firefox to read it as an audiofile and associate it with foobar by turning off the media.ogg.enabled and adding a new .oga type (perceived audio) in the registry, but it creates a catch-22: the html5 controls need media.ogg.enabled to true, which defaults it back to misinterpreting it as video (and launching the "corrupt video" page).

i'm convinced it's a hardcoding error, but you may be right - this may be fixed in a newer version, so i'm really heading to the vm now. 

if not, it's an easily recreated issue, by following the steps i presented.

Comment 7

[[e-mail]]

ok, i'm getting exactly the same behaviour in the virtual machine with an updated firefox - it's misreading the ogg flac as a video file, then telling me the video file is corrupt.

what i really wanted to know if this is *expected* to work, first and foremost. firefox _can_ read ogg. it _cannot_ read flac. so, the workaround is supposed to be to encapsulate the flac file in the ogg header. but, is that really expected to actually work?

Comment 8

[[e-mail]]

Attachment: requested screeen shot

Comment 9

[[e-mail]]

again, this is an ogg flac audio file (an audio flac file in an ogg container) and it decodes fine through foobar.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Desktop Firefox does not support playing back flac in Ogg, and probably never will unless we see significant demand. In Ogg we support Vorbis and Opus audio, and Theora video. I suggest you try Ogg/Vorbis, WebM/Vorbis or MP4/AAC.

Comment 11

[[e-mail]]

yeah. as mentioned, i'm building a front-end for a flac dvd, so it's a necessity that the files are lossless; it's a way to react to full discography torrent downloads, by putting the product people seem to want up for actual sale. it's like selling full concerts to try and stop bootleggers from eating into sales. i guess i'll have to skip the embedding and just hard code some playlists..

there's been some talk recently of windows natively supporting flac. that would create a situation similar to mp3s, which firefox can currently read only with an installed codec. i get that flac is a pain in the ass due to the transport layer (although i'm not quite sure why the encapsulation into ogg isn't an easily implemented fix), but would it be that far outside the realm of possibility for firefox to take a parallel position with flac and say "look, you can do this if you have your own codec."?

Comment 12

[Jean-Yves Avenard [:jya]]

Feel free to write the codec decoder...

Comment 13

[[e-mail]]

the point of encapsulation is that you don't need to - it sends the flac stream through the ogg container. but, this was a desperate workaround. the preferable choice would actually be to let the installed codec decode it, like you currently do with mp3s. it would actually take about five minutes to copy and paste the mp3 code and change the values to work with an installed flac decoder. but, the benefit of an html front-end (rather than one written in java or something) is that it doesn't require extra software. i don't want to have to bundle a forked firefox.

Comment 14

[cajbir (:cajbir)]

Have you considered using emscripten to compile a flac decoder and use WebAudio to play it? Something like the MP3 player examples? Actually, looks like someone has already done it: https://github.com/audiocogs/flac.js

This would then work on any browser that supports web audio.

Comment 15

[[e-mail]]

i ran into that when researching. it's workable; i remember having to that back in the day for mathml, when doing calculus assignments. but, i'm packaging the end product on a dvd, and really don't want to insist on telling people to turn on javascript. i know i'm forcing them to install a flac codec, but flac is entirely free (and needed to play the files in the first place) whereas java's a little iffy. i mean, like a lot of people, i run a javascript blocker by default, and have to turn it off when i access a site that uses it. as a consumer, i'd probably choose to skip it altogether - and wouldn't be able to expect people to take the opposite option, just because it's myself that's insisting on it. that's the benefit of html5 - clean, easy, no extras.

mozilla reversed their position on mp3s a few years ago with the argument that they ought not be restricting people's access to certain file types, so long as they provide their own decoders. but, i mean, there's not even patent issues with flacs. it strikes me as more of a conspiracy of network admins to try and reduce bandwidth. netflix is a nightmare on that point. and, in fairness, i can't argue it's worthwhile to stream flac through the speakers on your phone.

but, there are a lot of legit, local uses for html5 flac access. and, in the end, i expect that you'll cave on this, because there's really just not a good reason not to.

i need to backtrack on my statements about ogg flac, though, as i think i misunderstood the container/streaming relationship. i suppose one would still require a decoder, even after it's modified suitably for streaming.

Comment 16

[[e-mail]]

no, i was right, actually:

he native FLAC transport is not a transport "layer" in the way of standard codec design because it cannot be entirely separated from the payload. Though the metadata system can be separated, the frame header includes both data that belongs in the transport (sync pattern, timecode, checksum) and data that belongs in the compressed packets (audio parameters like channel assignments, sample rate, etc).

This presents a problem when trying to encapsulate FLAC in other true transport layers; the choice has to be made between redundancy and complexity. In pursuit of correctness, a mapping could be created that removed from native FLAC the transport data, and merged the remaining frame header information into the audio packets. The disadvantage is that current native FLAC decoder software could not be used to decode because of the tight coupling with the transport. Either a separate decoding implementation would have to be created and maintained, or an Ogg FLAC decoder would have to synthesize native FLAC frames from Ogg FLAC packets and feed them to a native FLAC decoder.

The alternative is to treat native FLAC frames as Ogg packets and accept the transport redundancy. It turns out that this is not much of a penalty; a maximum of 12 bytes per frame will be wasted. Given the common case of stereo CD audio encoded with a blocksize of 4096 samples, a compressed frame will be 4-16 Kbytes. The redundancy amounts to a fraction of a percent.

In the interest of simplicity and expediency, the second method was chosen for the first official FLAC->Ogg mapping. A mapping version is included in the first packet so that a less redundant mapping can be defined in the future.

from:
https://xiph.org/flac/ogg_mapping.html

so, i still don't understand why it doesn't work...

Comment 17

[[e-mail]]

wait. no. i was wrong. it's still native flac data and still needs decoding, even if it's an ogg packet. ok. got it.