Alternative method needed for determining audio file compatibility.

[nlowe]

We need a better way to decide on what provider to use for an audio/video file. For example, the SoundGstplayer implementation claims to only support ('wav', 'ogg', 'mp3') when in reality other containers and codecs are supported (Such as aac, audio only mp4's, flac, etc.). Oftentimes files will have the incorrect extension anyways. A work around consists of creating a subclass of the SoundGstplayer implementation and adding the additional return types and then manually registering the class. Should we consider looking at content types or just straight up trying to play/load the file by default?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[aspidites]

Haven't tried this, so forgive me if I'm missing something obvious, but given that extensions is a static method, isn't it enough to simply override it?

SoundGstplayer.extensions = lambda: ('wav', 'ogg', 'mp3', 'mp4', 'aac', 'flac')

That said, it could be beneficial to generate a list of supported file extensions dynamically. Should be trivial since extensions is a method, assuming the underlying library provides a way to list supported types. Off the top of my head I'm thinking that + mime type associations should do the trick.

[nlowe]

On my machine, yes, this fixes the issues, but I still feel this should be fixed / improved upstream instead of a per user and per project basis.

[aspidites]

And actually thats technically wrong, since it would no longer be a static method. At any rate, it was just a quick thought, and I agree that something more flexible should be done upstream. I don't think it's necessary to change the API to do so, though. In fact, I'm working on something now, so if you can give it about 5 minutes I should have something for you to test.

[aspidites]

So I lied about 5 minutes. I'm almost done though

[aspidites]

OK @techwiz24, can you try this patch and tell me if it works?

It only solves half the problem, as it recognizes other extensions. As for supported file formats, that is a separate issue (which I aim to address as well shortly).

[nlowe]

Nope, now it won't load any files, even those that worked previously.

[aspidites]

Interesting. I just tried the audio example included with kivy and it worked fine. Mind providing the minimum amount of code that used to work so that I can see what I broke?

[aspidites]

Nevermind, I know what happened. Gimme a sec

[nlowe]

Here's what I'm using to test with:

from kivy.core.audio import SoundLoader
s = SoundLoader.load(r"C:\test.wav") #also test.ogg, test.mp3, etc
s.play()

[aspidites]

Try this

[nlowe]

Only playing wav files. Still can't find a loader for aac/flac/mp3/ogg

[aspidites]

flac and aac are expected. mp3 and ogg not working are odd. Two things:

1. this should get the filetypes from before working
2. if you try python -c "import mimetypes; print(mimetypes.guess_all_extensions('audio/ogg'))" on the command line, what do you get?

[nlowe]

1. Nope

C:\Users\techwiz24\Projects\kivy-dev>python
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from kivy.core.audio import SoundLoader
[INFO              ] Kivy v1.8.1-dev
[INFO              ] [Python      ] v2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
[INFO              ] [Logger      ] Record log in C:\Users\techwiz24\.kivy\logs\kivy_14-03-02_22.txt
[INFO              ] [AudioGstplayer] Using Gstreamer 1.2.1.0
[DEBUG             ] [Audio       ] register SoundGstplayer
[DEBUG             ] [Audio       ] register SoundPygame
[INFO              ] [Audio       ] Providers: audio_gstplayer, audio_pygame (audio_sdl ignored)
>>> s = SoundLoader.load(r"C:\test.mp3")
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Users\techwiz24\Projects\kivy-dev\kivy\kivy\core\audio\__init__.py", line 63, in load
     if ext in classobj.extensions():
   File "C:\Users\techwiz24\Projects\kivy-dev\kivy\kivy\core\audio\audio_gstplayer.py", line 44, in extensions
     exts = set('ogg', 'wav', 'mp3')
 TypeError: set expected at most 1 arguments, got 3
>>> s = SoundLoader.load(r"C:\test.ogg")
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Users\techwiz24\Projects\kivy-dev\kivy\kivy\core\audio\__init__.py", line 63, in load
     if ext in classobj.extensions():
   File "C:\Users\techwiz24\Projects\kivy-dev\kivy\kivy\core\audio\audio_gstplayer.py", line 44, in extensions
     exts = set('ogg', 'wav', 'mp3')
 TypeError: set expected at most 1 arguments, got 3
>>> exit()

1. Perhaps something wrong with my environment?

C:\Users\techwiz24\Projects\kivy-dev>python -c "import mimetypes; print(mimetypes.guess_all_extensions('audio/ogg'))"
[]

Does this work on your system?

[aspidites]

The first part of that is my fault. set takes a single argument. The second part seems to indicate that mimetypes aren't properly set up on your system, which explains why oggs were failing with my previous commit.

Let's give it another try

For the record, I'm not currently set up to use the gstplayer which is how I missed this.

BTW, on my system, I get:

$ python -c "import mimetypes; print(mimetypes.guess_all_extensions('audio/ogg'))"
['.oga', '.ogg', '.opus', '.spx']

update: This article on mimetypes in windows seems to be relevant. That said, I use a fallback so that users shouldn't have to muck with mimetypes if their environment isn't set up for them. Just thought you'd be interested to see if they were set up correctly on your system..

[nlowe]

I can now play the same formats as before.

[aspidites]

Alright, so the moral of the story is that while detecting extensions by mimetypes seemed like a good idea, its unreliable if the user's mimetypes aren't set up properly. Back to the drawing board.

Given that trying to open an unsupported format causes a crash anyway, it seems like it would make more since to just try it anyway.

I've not been able to test this, but could you tell me what the result of this is?

[nlowe]

Same result. I can play wav and ogg files. MP3 files reports a missing GStreamer plug-in (Does it expect LAME in a certain place?). I can't play flac/aac/mp4 audio files.

[aspidites]

See the official plugin page for more details, but I think you need gst-plugins-ugy. If you re-run the gstreamer installer for windows and select a custom install (instead of typical), you should be able to select it from there.

As for flac, aac, and mp4, those should be in gst-plugins-good and gst-plugins-bad.

When you say "can't play ..." do you mean that no errors at all show up, or that you get similar gstreamer plug-in errors?

[nlowe]

Sorry, by can't play I mean for MP3's I get the gstreamer plug in errors, and for flac/aac/mp4 kivy can't find a loader for them. If I manually edit in the extension they work fine.

[connor-k-smith]

I had a related question (sorry, very new to all of this, hope I'm explaining it correctly):

My goal is to be able to play a Flac file.
When using Kivy 1.8 in Windows, I can edit the extensions as described above and then successful play flac files. For testing purposes, I'm just manually editing audio_gstplayer.py as follows:

class SoundGstplayer(Sound):
    @staticmethod
    def extensions():
        return ('wav', 'ogg', 'mp3', 'flac')

This is working fine, and I am able to play Flac via the Kivy program on my PC.

However, if I then transfer over to a linux VE to build an .apk with buildozer, I always get a "Unable to find a loader for test.flac" error message in logcat when I try to load the .flac file. The logcat shows:

register SoundPygame
Providers: audio_pygame (audio_pygst, audio_sdl ifnored)
Unable to find a loader for ....test.flac

^^Even though, I've edited the SoundPygame extensions in audio_pygst.py as I did in the above on the Windows side of things:

Any ideas on how to get the Flac support when I move over to android?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.