Closed noahsark769 closed 8 years ago
Wait have we actually tested this? Because MP3 works on Firefox, even though it says no on there...
Yeah, doesn't work on Safari, two people have submitted bug reports so far. Also I think soundmanager should know how to handle this anyway? Not sure...
Do we know why it won't recognize the file? Because the code that actually checks for validity of the file is in our code, right? Not in the browser?
Yeah, supposedly. Will have to look more into it, but the error seems to be coming from our end - not sure why it works on Chrome and not Safari though
Oh yeah, but definitely it seems as if the problem is not related to the above chart, so I'll edit that. Sorry haha
^ error potentially in the soundmanager vendor code
Might be related to http://www.schillmania.com/projects/soundmanager2/doc/#soundmanager-audioformats: we should make .ogg a "required" format I think
:+1:
Sooo debugging this is gonna be freaking hard, because Safari doesn't like uploading audio files (even mp3) on localhost for some reason
Noah's right that Soundmanager is supposed to handle this. When the browser can't support ogg, soundmanager is supposed to fall back on flash.
Is it possibly something to do with safari loading it as a file? Would running it locally under a python SimpleHTTPServer work?
If we're lucky I've already fixed the problem -- I found a bug a few minutes ago. I wasn't giving a valid url for the location of the files that soundmanager needed to work with flash
I'll push the branch in with the fix; it would be great if someone with a mac could see if this fixes the problem
@kmdurand I can verify that if you open a pull request
kk will do once i figure out why it's not pushing :P
alright haha got the branch up
So looks like this is an unsolvable issue because flash can't play ogg's either. We have to look into either distributing wav files or doing something else.
Closing as wontfix
just opening this up again, because we've got another response about safari and ogg. are we going to distribute other formats as well, or leave people wondering?
I think having a warning show on safari is the best thing to do here if safari can definitely not play ogg's On Fri, Sep 25, 2015 at 9:02 AM Brandon Chinn notifications@github.com wrote:
just opening this up again, because we've got another response about safari and ogg. are we going to distribute other formats as well, or leave people wondering?
— Reply to this email directly or view it on GitHub https://github.com/calband/calchart-viewer/issues/112#issuecomment-143261758 .
:+1: see PR
Why not just convert the files to another format, like aac or mp3?
Richard
On Sep 25, 2015, at 5:20 PM, Brandon Chinn notifications@github.com wrote:
see PR
— Reply to this email directly or view it on GitHub https://github.com/calband/calchart-viewer/issues/112#issuecomment-143381759.
@rmpowell77: as I recall from last year, we were having some problems with how mp3 files you sometimes not get synced correctly with the animation, and the same problem didn't happen with oggs. (see #63). AAC could be another option: however, it wouldn't be bad to have this warning in any case.
If I remember correctly, we stopped using MP3 files because they're encoded in a way that makes it difficult to begin playback from a particular moment of the music. When we asked our music player to begin playing music from some time xx:xx, it was only able to approximate the starting point in the file, so the music wasn't quite in sync with the animated dots.
Haven't looked into AAC though. That might be a good alternative.
Did some reading. Ogg isn’t really the same as MP3. Ogg is technically the container for the audio content, which is actually Vorbis. As a container, Ogg probably contains an index table that a parser is able to decode and determine where particular offsets in a file are. Vorbis is closer to what mp3 is, the encoded bitstream of audio data.
Mp3 has two interesting modes, Constant bit rate (CBR) and Variable bit rate (VBR). With CBR, 1024 frames (23 ms @ 44.1 kHz) will take a fixed amount of bytes (more or less), but at VBR, it will take anywhere from 7 up to X, whatever the top bound by the encoder is set to based on the quality desired. This means that if you have an MP3 file with VBR it is very hard to determine where the offset of the file at a particular time is, where to drop the needle, if you will.
MP4 is a container format specified by the MPEG standard, very much like Ogg. MP4 can contain a wide variety of content formats, like MP3 and AAC. MP4 files that contain just audio are often called M4A files.
So Ogg is to M4A as Vorbis is to MP3.
Perhaps the issue is that we should also support M4A or other container formats instead of MP3?
Richard
On Sep 28, 2015, at 12:15 AM, kmdurand notifications@github.com wrote:
If I remember correctly, we stopped using MP3 files because they're encoded in a way that makes it difficult to begin playback from a particular moment of the music. When we asked our music player to begin playing music from some time xx:xx, it was only able to approximate the starting point in the file, so the music wasn't quite in sync with the animated dots.
— Reply to this email directly or view it on GitHub https://github.com/calband/calchart-viewer/issues/112#issuecomment-143657917.
Wow thanks @rmpowell77. With that in mind, I went again to go check out the audio file formats that are supported by different browsers, and I found this chart. It looks to me like AAC contained in MP4 seems like a good bet for us.
Hmm it seems like using .aac
files works pretty well. I tried the P!nk show again and it seems to at least work better than mp3.
Test files: 2014_p!nk_show.zip
Gonna close this as a good-for-now.
For some reason, it seems the FSM show .ogg isn't being accepted as a valid file on Safari. Possibly related to the file extension, more possible a bug in our validation code.