1. pygame
  2. pygame
  3. pygame
  4. Issues


Issue #69 wontfix

pygame.mixer.music.load Corrupt MIDI file

René Dudfield
created an issue

== Anton, 2011-04-22 06:01:15 -0700

{{{ Hi,

I'm trying to play a karaoke file via pykaraoke (http://kibosh.org/pykaraoke/index.php)

It uses pygame.mixer and a big number of files wouldn't play from my collection. I've figured that this is a possible bug in pygame library. Bellow is the error message:

$ python pykar.py ty_u_menya.kar File "pykar.py", line 1450, in <module> sys.exit(main()) File "pykar.py", line 1444, in main player = midPlayer(None, None) File "pykar.py", line 1068, in init pygame.mixer.music.load(audio_path) pygame.error: /usr/share/timidity/eawpatches/xgmap2.cfg: Corrupt MIDI file.

I've tried to play it with 3 different timidity patches: [1] eawpatches [2] shompatches [3] freepats but the error is the same (corrupt MIDI file).

I'm attaching "ty_u_menya.kar" for your tests. Please let me know if you need more information.

Thank you. }}}

== Anton, 2011-04-22 06:01:55 -0700

{{{ Created attachment 44 a test karaoke file }}}

Attachments: [[http://www.pygame.org/old_bug_attachments/44/ty_u_menya.kar| ty_u_menya.kar]]

== Anton, 2011-04-22 06:04:31 -0700

{{{ One more thing.

I've tried to play it using timidity library: timidity ty_u_menya.kar

and it works fine.

so it really look like a pygame bug. }}}

Comments (17)

  1. Anton_B

    I've just cloned the current hq version and compiled it successfully under Linux. However it failed to run with the following error:

       File "pykar.py", line 142, in <module>
        from pykplayer import pykPlayer
      File "/usr/lib64/python2.7/site-packages/pykplayer.py", line 24, in <module>
        from pykmanager import manager
      File "/usr/lib64/python2.7/site-packages/pykmanager.py", line 26, in <module>
        import pygame
      File "/usr/lib64/python2.7/site-packages/pygame/__init__.py", line 260, in <module>
        try: import pygame.surfarray
      File "/usr/lib64/python2.7/site-packages/pygame/surfarray.py", line 72, in <module>
        import pygame._numpysurfarray as numpysf
      File "/usr/lib64/python2.7/site-packages/pygame/_numpysurfarray.py", line 56, in <module>
        numpy_floats = [numpy.float, numpy.float32, numpy.float64, numpy.float96]
    AttributeError: 'module' object has no attribute 'float96'

    The following changelog might give you a clue: http://projects.scipy.org/scipy/changeset/4172

    Could you have a look please?

    ps. I have replaced the float96 with longdouble, however the original error has came back:

    Traceback (most recent call last):
      File "pykar.py", line 1434, in <module>
      File "pykar.py", line 1428, in main
        player = midPlayer(None, None)
      File "pykar.py", line 1053, in __init__
    pygame.error: /usr/share/timidity/eawpatches/xgmap2.cfg: Corrupt MIDI file.
  2. René Dudfield reporter
    • changed status to open

    I think the windows binaries play the music with native midi, not timidity.

    I tried this on OSX:

    >>> pygame.init()
    >>> pygame.mixer.init()
    >>> pygame.mixer.music.load(open("ty_u_menya.kar", "rb"))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>

    I don't think timidity is used on this OSX build... I could be wrong though.

    Then I looked in the pygame music.c code, and the error appears to come from the SDL_mixer Mix_LoadMUS call.

    I tried to rename it to "ty_u_menya.mid" just in case it had an issue with the file name, but got the same error.

    Next we need to test if it is a problem with SDL_mixer. There is a playmus.c example that comes with SDL_mixer. Are you able to try playing the music with that? If you need help compiling playmus.c, let me know and I'll find out the commands on linux for you.


  3. Anton_B

    Nop, I'm unable to playback that file with playmus either:

    ./playmus ty_u_menya.kar Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer Couldn't load ty_u_menya.kar: /usr/share/timidity/eawpatches/xgmap2.cfg: Corrupt MIDI file.

    So it is SDL_mixer library bug, isn't it? But why timidity can play it?

  4. pygame repo owner

    ah, that's interesting. I wonder if timidity is linked to your sdl_mixer.so or if it is trying to do midi some other way.

    $ ldd /usr/lib/libsdl_mixer.so

    That should tell us if timidity is involved. It does look like an sdl_mixer bug, or whatever sdl_mixer is using to play midi.

    I'll debug it when I get my linux machine back (it's being used in windows mode as an internet router at the moment, so I can't reboot it).


  5. Anton_B

    Here you go:

    ldd /usr/lib64/libSDL_mixer.so
    	linux-vdso.so.1 =>  (0x00006a12046e7000)
    	libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00006a120425a000)
    	libsmpeg-0.4.so.0 => /usr/lib/libsmpeg-0.4.so.0 (0x00006a1203ff8000)
    	libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00006a1203d90000)
    	libpthread.so.0 => /lib64/libpthread.so.0 (0x00006a1203b4b000)
    	libc.so.6 => /lib64/libc.so.6 (0x00006a12037e3000)
    	libm.so.6 => /lib64/libm.so.6 (0x00006a1203562000)
    	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6 (0x00006a1203231000)
    	libasound.so.2 => /usr/lib64/libasound.so.2 (0x00006a1202f3a000)
    	libdl.so.2 => /lib64/libdl.so.2 (0x00006a1202d36000)
    	/lib64/ld-linux-x86-64.so.2 (0x00006a12046e8000)
    	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00006a1202b1f000)
    	librt.so.1 => /lib64/librt.so.1 (0x00006a1202915000)

    ps. Can you run linux under vmware/virtualpc? linux is better as a router anyways ;-)

  6. René Dudfield reporter

    Ah, it doesn't look like it links to timidity statically. Maybe it loads it dynamically though.

    I found out that sdl_mixer looks for a TIMIDITY_CFG environment variable.

    TIMIDITY_CFG=yourfile.cfg ./playmus ty_u_menya.kar

    Maybe that will help? However, from your command it looks like maybe it was already using timidity.

    I looked on OSX what my libSDL_mixer.dylib is linked to, and it does not link to timidity either.

    otool -L /usr/local/lib/libSDL_mixer.dylib 
    	/usr/local/lib/libSDL_mixer-1.2.0.dylib (compatibility version 11.0.0, current version 11.1.0)
    	/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.3.0)
    	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 17.0.0)
    	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
    	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
    	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)
    	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
    	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
  7. Anton_B

    The variable didn't help unfortunately.

    Based on gentoo's ebuild, sdl-mixer can be compiled with timidity support: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/sdl-mixer/sdl-mixer-1.2.11-r1.ebuild?revision=1.9&view=markup

    And I did compile it with following flags ( "-" means disabled): media-libs/sdl-mixer-1.2.11-r1 USE="flac midi mp3 timidity wav -mad -mikmod -static-libs -vorbis"

    So timidity and midi are enabled and compiled dynamically.

  8. Anton_B

    Thanks guys for opening the new thread on the SDL forum http://forums.libsdl.org/viewtopic.php?t=7501. I can't post there, so here is a small update. I tried to re-compile sdl-mixer with different options, still no luck:

    • disable-mixer, disable-timidity enable-music-native-midi: "Unrecognized music format"
    • disable-mixer, enable-timidity enable-music-native-midi: No sound, no errors.
    • enable-music-native-midi-gpl: unable to compile (native_midi_gpl/playmidi.h:56:29: error: linux/awe_voice.h: No such file or directory)
  9. Anonymous

    SDL_mixer uses it's own timidity. It doesn't link to it or anything, but comes bundled with an extremely outdated version of timidity (the original timidity, not "timidity++" which is what people mean when they say "timidity" today.")

    Furthermore, SDL_mixer is not able to use any externally installed version of timidity, only the one it comes bundled with. In the future, SDL_mixer will use FluidSynth if it's available on the system.

    So this bug is SDL_mixer's fault; its bundled version of timidity cannot cope correctly with karaoke MIDI files.

  10. René Dudfield reporter


    I sent a follow up email linking to the sdl bug tracker.

    As a work around, perhaps on linux you could call the timidity process?

    Something like:

    import subprocess, platform
    if "linux" in platform.platform():
        subprocess.call(["timidity", "filename.midi"])

    Sorry I couldn't help, but I guess we found the bug with sdl_mixer, so that's good. Thanks heaps for help in tracking down the problem.

  11. Anton_B

    @illiume: That won't be good enough I'm afraid. Pykaraoke need to know a current position to display lyrics in a proper timing and you can't get it from the external process if I'm not wrong. So it really has to be a patch for SDL library. Unless you can propose a workaround for the pygame (which is just a wasting time I guess).

    Anyways, I want to thank you one more time guys. You were extremely helpful.

  12. Log in to comment