You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Transferred from Bugzilla, #13. Have not re-confirmed this but transferring it as it appears not to have been closed.)
I have found an edge-case whereby HTML5 audio on Mac OS X (QuickTime backend) plays the wrong MP3 clip range (i.e. what is audible is "in the future"), and reports incorrect position updates (i.e. audio.currentPosition values are in the past).
I am not sure if it is due to the MP3 encoding (VBR, Lame settings?), but it seems to happen pass a certain point in the MP3, like if there was some kind of misaligned "keyframe". It seems related to seeking, because this behaviour only occurs when forcing the playback to start at a given point: like when mouse-clicking on an arbitrary HTML element, rather than letting the audio play from the start.
I am able to consistently reproduce the exact same erroneous audio playback offset, regardless of the asset delivery mechanism in LauncherOSX ("hidden" temporary filesystem storage vs. local HTTP streaming server).
(Transferred from Bugzilla, #13. Have not re-confirmed this but transferring it as it appears not to have been closed.)
I have found an edge-case whereby HTML5 audio on Mac OS X (QuickTime backend) plays the wrong MP3 clip range (i.e. what is audible is "in the future"), and reports incorrect position updates (i.e. audio.currentPosition values are in the past).
I am not sure if it is due to the MP3 encoding (VBR, Lame settings?), but it seems to happen pass a certain point in the MP3, like if there was some kind of misaligned "keyframe". It seems related to seeking, because this behaviour only occurs when forcing the playback to start at a given point: like when mouse-clicking on an arbitrary HTML element, rather than letting the audio play from the start.
I am able to consistently reproduce the exact same erroneous audio playback offset, regardless of the asset delivery mechanism in LauncherOSX ("hidden" temporary filesystem storage vs. local HTTP streaming server).
If you want to try yourselves, AChristmasCarolAudioBook.epub is linked from our list of sample/test books:
https://docs.google.com/document/d/1_4tsFq_4Xr-jVbqY3brkVXAL3_UJLQiZWl47SH-I0bM
Obviously, I cross-checked the SMIL synchronisation, and made sure to eliminate other potential factors.
Here is a typical log of clip Begin / End values:
TO
28.681
25.312 (reported about 25x in row)
25.248
25.268
25.288
25.309
...
As you can see, the timestamp series above seems to "jump back in the past", and then continues progressing as normal.
See:
https://groups.google.com/forum/#!topic/readium-sdk-contrib/IVoHA4jmByM
Additional Comment by Daniel:
I am able to reproduce this behaviour consistently with SDKLauncher-Android as well.
The text was updated successfully, but these errors were encountered: