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

segmentation fault on 11025 hz MP3 files (music_sdl) #372

Closed
ohrrpgce-bugbot opened this issue May 2, 2007 · 40 comments
Closed

segmentation fault on 11025 hz MP3 files (music_sdl) #372

ohrrpgce-bugbot opened this issue May 2, 2007 · 40 comments
Labels
bug Yeah... that's broken crash Bugs causing a crash, freeze/hang, abort(), or FB fatal error music_sdl music rel: ancient Present for a long time, possibly forever

Comments

@ohrrpgce-bugbot
Copy link

[bz#372]

I downloaded Fenrir Lunaris's "OHR SACHEN Multipack" from http://www.castleparadox.com/gamelist-display.php?game=827 and played until I got the wolf-and-sheep game. When I talked to a sheep, I enter battle, and the OHR immediately crashed.

I opened it in custom, and found the song that plays in that battle, and it crashed.

I'll attach that song to this bug. it is in MP3 format. None of the other MP3's in that game crash.

I have only tested this on Linux with music_sdl so far. it does not occur with the music_silence backend. (I haven't had a cance to test music_native yet)

From: @bob-the-hamster
Reported version: 20070921 Ubersetzung
URL: http://www.castleparadox.com/gamelist-display.php?game=827
Blocker for: bz⁠#255

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 103
cheesy battle music from OHR SACHEN Multipack

Attached file: song10.mp3 (audio/mpeg, 231340 bytes)
Description: cheesy battle music from OHR SACHEN Multipack

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

On further examination, none of the MP3 format songs in OHR MULTIPAK work. Song 10 crashes instantly. Song 17 plays some garbled static and then crashes, and all the other MP3's are silent.

Looking at the files in audacity, I see that they are all recorded at 11025 Hz (except for song 11, which is 16000 Hz)

Typical MP3 files (like all the ones I have tested with in the past) are usually 44100 Hz

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Actually, song 11 (the one that is 16000 Hz) works fine. Only the 11025 Hz songs are silent and/or crashy

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

This is not linux specific. It happens *almost* exactly the same in Windows.

The only difference is that on Windows, there is a delay of about 1 second before song 10 crashes.

I did some debugging in Linux, and discovered that the song does get loaded successfully, and the crash happens at some point later (maybe in a separate music thread?)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I tested a variety of other common sampling rates.

8000 No sound
11025 No sound or garbled sound or crash
16000 Plays too fast
22050 Plays just fine
44100 Plays just fine (almost all mp3 is recorded at this rate)
48000 Plaaaaayssss slooooowwwwllyyy
96000 Plaaaaaaysssss sloooooowwwwwlllyyyy

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Oh, it is also worth mentioning that the size difference between MP3 files sampled at different rates is very small, so there is only minimal size advantage to recording your MP3s at lower rates.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I repeated the same test with ogg vorbis instead of mp3:

8000 Plays too fast
11025 Plays just fine
16000 Plays just slightly too fast
22050 Plays just fine
44100 Plays just fine
48000 Plays just slightly too slow
96000 Plays to slow (but not as slow as a 48000 mp3)

I also tested with wav files (as sound effects, not as music) and the results were exactly the same as with ogg vorbis files.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

And also, for completeness, I tested with music_native.

All the ogg files work perfectly
All the wav files work perfectly.
All the mp3 files work perfectly *except* for the 8000 Hz one, which as a loud staticy "SPBLURK!" noise inserted at the beginning.

And with music_native, exiting the music import screen causes a crash (but not the sound effects import screen). I spun off bug bz⁠#400 for that problem

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

How about this?

If we can write some code that detects the rate of n MP3 file, we can work around this problem.

If a MP3 uses an unsupported rate, music_sdl will just refuse to play it. And no matter which backend you use, CUSTOM will provide a warning when you try to import an unsupported MP3.

That way, existing games like OHR SACHEN Multipack which already use troublesome MP3s will work on music_native, and at least will not crash on music_sdl, and the warning will discourage users from importing odd MP3 rates in the future.

Sound reasonable?

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 108
8000 Hz test mp3

Attached file: 08000.mp3 (audio/mpeg, 31142 bytes)
Description: 8000 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 109
11025 Hz test mp3

Attached file: 11025.mp3 (audio/mpeg, 33473 bytes)
Description: 11025 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 110
16000 Hz test mp3

Attached file: 16000.mp3 (audio/mpeg, 32294 bytes)
Description: 16000 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 111
22050 Hz test mp3

Attached file: 22050.mp3 (audio/mpeg, 37653 bytes)
Description: 22050 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 112
44100 Hz test mp3

Attached file: 44100.mp3 (audio/mpeg, 37653 bytes)
Description: 44100 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 113
48000 Hz test mp3

Attached file: 48000.mp3 (audio/mpeg, 38822 bytes)
Description: 48000 Hz test mp3

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 114
INCOMPLETE FreeBasic code to detect mp3 frequency

This is incomplete. It does work correctly on the sample mp3 files I have attached, but it is NOT good for general use because it only looks at the first frame it finds. The frequency of the first frame is not always the same as the frequency of the whole file (something to do with optional Variable Bit Rate, I guess) When I run this on my collection of MP3 songs, it correctly detects only approx 80% ~ 90% of them :(

Attached file: mp3info.bas (text/plain, 2772 bytes)
Description: INCOMPLETE FreeBasic code to detect mp3 frequency

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 115
header file for mp3 frequency detection code

Attached file: mp3info.bi (text/plain, 369 bytes)
Description: header file for mp3 frequency detection code

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I see no practical way to programatically detect unsupported MP3 files that isn't close in complexity to implementing our own full-feature MPEG decoder with all versions of ID3 and variable bit rate support in FreeBasic... which is not something I desire to do.

The only simple reliable way to eliminate this crash is to just flat out forbid MP3 format... but that really sucks too, and I don't want to do it.

Which leaves us with the option of ignoring the bug, and clearly documenting the fact that only 22050 and 44100 are to be used. If somebody tries to use an unsupported version, they crash, read the FAQ, and learn what they did wrong. This solution sucks too.

Which of these three options is least awful? Discussion?

  1. Re-invent a *VERY LARGE* wheel just to know which mp3 files to refuse to play.
  2. Discard support the most popular digital music format, saying "Convert to OGG, you n00bz!"
  3. Give up and accept a serious crash, document it, pretend nothing is wrong.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

Option 4: Take TMC's suggestion, and convert everything to OGG first.

I vote for #⁠4

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Option 4: Take TMC's suggestion, and convert everything to OGG first.

I vote for #⁠4

You mean making the CUSTOM automatically convert MP3 into OGG when you import? That would require bundling an mp3 player and an ogg encoder with custom (and if we had the mp3 player, this wouldn't be a problem in the first place)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

I'm sure that somewhere, there's a nice simple library, probably on SourceForge, that we could integrate. I, Mike, will dedicate my life to finding it.

End Transmission

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I'm sure that somewhere, there's a nice simple library, probably on
SourceForge, that we could integrate. I, Mike, will dedicate my life to finding
it.

End Transmission

Let's disable Mp3 for now, and then add it back using the above-mentioned method after ubersetzung. I am hungry (nay, starving!) for a stable release.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

I found something promising, in MAD (http://www.underbit.com/products/mad/). It apparently can decode MP3s, so we could use it to decode MP3s to WAVs at run time. In that case, we don't really need to convert to OGG again, as that would just be a waste of processor time.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @arperry

Ooh! Would that let us use MP3s as sound effects? Say yes.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

I suppose it would. :)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

According to http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL_mixer/CHANGES?revision=3329&view=markup version 1.2.8 of SDL_mixer supports libMAD for playing MP3 files... I believe it is an optional compile-time option.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @ziggythehamster

I don't like the idea of transcoding OR the idea of WAV dumping. A 4MB MP3 gets to be huge as a WAV, and though a lot of us have a lot of bandwidth, what about the poor souls on dialup?

If I had to choose, I'd say either 1) try and use a better decoder (I thought you guys were ALREADY using MAD, so I didn't say anything), or 2) transcode to Ogg on import. If you didn't want to do the code yourself, you could shell out to madplay and oggenc:

madplay -o wave:out.wav infile.mp3
oggenc -q 7 -o out.ogg out.wav # where -q 7 is quality value 7/10

And both run on Windows. On Linux both utilities should already be installed, so I don't see it being a big deal to say you need madplay/oggenc installed to add MP3s.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

Um, we wouldn't transcode them on import. That would be stupid. We would do it at run time, where the impact is less.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Um, we wouldn't transcode them on import. That would be stupid. We would do it
at run time, where the impact is less.

Import-time transcoding from MP3->OGG makes sense.

Run time transcoding from MP3->WAV might work, but could be a performance problem.

I actually like the idea that Keith Gable just suggested. At import-time, detect whether the external tools for MP3->OGG conversion are available. If so, transcode, if not, disallow MP3 import with an error message explaining that you need to install the external converters. This is my favorite idea so far.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

I personally think the best solution is dumping/patching SDL_mixer (because it's buggy all over, and a hazard), but that's probably not feasible. So the most promising solution is libmad.

I've just found another problem: sdl_mixer doesn't play back low rate wav files properly either. Windows XP Startup.wav, which I had lying around, is 8000HZ 8bit mono, and sounds totally wrong.

Also, music_native has a loud noise at the beginning when playing the 8000Hz test, but the battle music and all the rest are fine.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I personally think the best solution is dumping/patching SDL_mixer (because
it's buggy all over, and a hazard), but that's probably not feasible. So the
most promising solution is libmad.

Well, sdl_mixer is depressingly buggy in the frequency department, but in my experience it is highly stable in all other ways.

music_native still doesn't work on linux (not for me anyway), and I believe all of our music-related ubersetzung blockers other than this one are music_native-specific.

But yes, that could be an option. If we can solve all the outstanding music_native problems, then I would feel a lot more comfortable about taking the "option 3" that I mentioned in comment 18

I've just found another problem: sdl_mixer doesn't play back low rate wav files
properly either. Windows XP Startup.wav, which I had lying around, is 8000HZ
8bit mono, and sounds totally wrong.

Yeah, that is right. See comment 7. SDL mixer only reliably plays 22050 Hz or 44100 Hz (though only MP3 format ever results in silence or crashing)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

*** Bug bz⁠#316 has been marked as a duplicate of this bug. ***

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Okay, here is the plan. We will convert MP3 to OGG format on import. If madplay and oggenc are unavailable, MP3 import will be disabled.

Here is the implementation plan I will follow. Comment here if you want to take care of one of these steps.

Step 1)
Disable MP3 import (this is the only step that blocks ubersetzung, although all the rest of the steps will be accepted and are definitely desired before ubersetzung)

Step 2)
Write code that can detect the presence of madplay and oggenc

Step 3)
Write code that can convert an MP3 to an OGG

Step 4)
Re-enable MP3 import using the code from step 2 and 3

Step 5) Write a simple UI that lets you choose OGG quality (and pick a sensible default)

Step 6) Adapt the above steps to do the same for WAV files

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

All the steps I described in comment 33 are finished, marking this bug fixed.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

er... *actually* marking fixed.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

Is it possible to change the frequency when converting to OGG to something more normal? However I notice 8000Hz and 11025Hz MP3 and WAV files don't convert at all. (Including that windows startup wav, which is previewable but converts to silence)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Is it possible to change the frequency when converting to OGG to something more
normal? However I notice 8000Hz and 11025Hz MP3 and WAV files don't convert at
all. (Including that windows startup wav, which is previewable but converts to
silence)

Yes, actually, I believe oggenc has a command-line option to resample to a different frequency

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Is it possible to change the frequency when converting to OGG to something more
normal? However I notice 8000Hz and 11025Hz MP3 and WAV files don't convert at
all. (Including that windows startup wav, which is previewable but converts to
silence)

Hmmmm... looks like we have two problems here...

(1) madplay can't decode MPEG-2.5 which is the unofficial spec that allows 8000 Hz and 11025 Hz MP3 files. (strangely enough, mpg321 has no problem with these, and it claims to use libmad)

(2) A correctly converted (with mpg321) 8000 Hz WAV file converts to silence with oggenc regardless of resampling.

At least nothing bloddy crashes. :P

@ohrrpgce-bugbot
Copy link
Author

Comment author: @ziggythehamster

We can upconvert sampling rates with sox.

I think something like this will work:

sox out.wav -r 44100 out_resampled.wav

(testing on my linux box)

Also, official Windows port available -> http://sox.sourceforge.net/

@ohrrpgce-bugbot
Copy link
Author

Comment author: @ziggythehamster

I'm seeing the same issues with 8khz files. Odd.

sox does upconvert just fine though.

@ohrrpgce-bugbot ohrrpgce-bugbot added music_sdl bug Yeah... that's broken rel: ubersetzung Present in ubersetzung 2007-09-21 labels Mar 14, 2020
@rversteegen rversteegen added crash Bugs causing a crash, freeze/hang, abort(), or FB fatal error music rel: ancient Present for a long time, possibly forever and removed rel: ubersetzung Present in ubersetzung 2007-09-21 labels Mar 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Yeah... that's broken crash Bugs causing a crash, freeze/hang, abort(), or FB fatal error music_sdl music rel: ancient Present for a long time, possibly forever
Projects
None yet
Development

No branches or pull requests

2 participants