3

I am using just_audio in flutter to play audio files. All is lovely, except that just_audio uses the file-name extension to determine the file type. Therefore, if your URL does not end with the appropriate few characters, then you cannot play the file. From reading the issues on GitHub there appears to be a way to side-step this problem (#86 and #87) but I'm afraid I don't understand the answer.

Can some-one point me to an easy way to play such a URL?

Ways to replicate the issue:

  1. Download the example project from just_audio
  2. Replace one of the URIs with https://www.dropbox.com/s/egtn3aavqggpdj2/Bible_ResurrectionLife.mp3%3Fdl=1
  3. When you attempt to play the audio file, you should see the following error:
flutter: An error occured (-11800) The operation could not be completed
[VERBOSE-2:ui_dart_state.cc(177)] Unhandled Exception: PlatformException(-11800, The operation could not be completed, null, null)
Neill Bowler
  • 145
  • 1
  • 10
  • I am afraid that you would need to check the first few bytes of the file yourself. The information about the real nature of a file is contained in its header (first few bytes). – Antonin GAVREL Feb 20 '21 at 15:06
  • Thanks. I can guarantee the actual file type, since I uploaded it. Unfortunately just_audio refuses to work with it. – Neill Bowler Feb 20 '21 at 19:45
  • Im afraid that you would have to make a PR (pull request) to just_audio so that your format can work. – Antonin GAVREL Feb 20 '21 at 19:55

1 Answers1

2

The first GitHub issue you linked to doesn't apply in your case since it involves the detection of HLS or Dash streams specifically on Android. MP3 files on both iOS and Android are determined not by the file extension but by the HTTP headers.

In the case specifically of iOS's detection of the audio file content type, the file extension is only important when dealing with files. For URLs, it's the Content-Type HTTP header that iOS uses to determine the type of audio. iOS additionally has a requirement that the server must support byte range requests (see Apple's explanation).

It is likely that Dropbox is failing one of these requirements.

Two solutions come to mind:

  1. Host the MP3 file on a server that is capable of supporting the headers that iOS requires.

  2. You could try using just_audio's LockCachingAudioSource. This is intended to cache the audio while it's being simultaneously played and downloaded. Although you may not be interested in that feature, the way it is implemented is by inserting a proxy between the iOS media player and the server. The proxy is implemented in a way that supports byte-range requests, although it won't necessarily be able to fulfill a byte range request to the end of the file until the cache has completely downloaded the file. Since it's your mp3 file, you could try encoding the mp3 file in a way that is optimised for streaming so that iOS doesn't need to jump to the end of the file to find metadata. Since the implementation of LockCachingAudioSource is available as part of the open source project, you could also make your own version of it that takes out the caching part if you don't need it.

Ryan Heise
  • 2,273
  • 5
  • 14
  • Thanks Ryan for the detailed explanation. I haven't been able to get `LockCachingAudioSource` to work for me. I'll think about whether to use an alternative cloud storage to dropbox (although dropbox gives direct links to files and no download limits). For the time being I'll probably download, rather than stream, the files. – Neill Bowler Feb 21 '21 at 17:53