Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Media Overlays, some MP3 encoding settings seem to corrupt playback #72

Closed
rkwright opened this issue Jul 25, 2014 · 2 comments
Closed

Comments

@rkwright
Copy link
Member

(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:

SHOULD PLAY:
FROM
25.312

TO
28.681

AUDIO POSITIONS (sampled every 20ms):

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.

@rkwright
Copy link
Member Author

Re-tested with 0.25-alpha on OSX 10.11 on a MBP. Verified that there are some errors. This seems to be authoring error. Why isn't this closed?

@danielweck
Copy link
Member

closing, as stale issue and not been reproduced since.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants