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
Comments
Comment author: @bob-the-hamster Created attachment 103
|
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 |
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 |
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?) |
Comment author: @bob-the-hamster I tested a variety of other common sampling rates. 8000 No sound |
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. |
Comment author: @bob-the-hamster I repeated the same test with ogg vorbis instead of mp3: 8000 Plays too fast I also tested with wav files (as sound effects, not as music) and the results were exactly the same as with ogg vorbis files. |
Comment author: @bob-the-hamster And also, for completeness, I tested with music_native. All the ogg files work perfectly 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 |
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? |
Comment author: @bob-the-hamster Created attachment 108
|
Comment author: @bob-the-hamster Created attachment 109
|
Comment author: @bob-the-hamster Created attachment 110
|
Comment author: @bob-the-hamster Created attachment 111
|
Comment author: @bob-the-hamster Created attachment 112
|
Comment author: @bob-the-hamster Created attachment 113
|
Comment author: @bob-the-hamster Created attachment 114 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 :(
|
Comment author: @bob-the-hamster Created attachment 115
|
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?
|
Comment author: @pkmnfrk Option 4: Take TMC's suggestion, and convert everything to OGG first. I vote for #4 |
Comment author: @bob-the-hamster
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) |
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 |
Comment author: @bob-the-hamster
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. |
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. |
Comment author: @arperry Ooh! Would that let us use MP3s as sound effects? Say yes. |
Comment author: @pkmnfrk I suppose it would. :) |
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. |
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 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. |
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. |
Comment author: @bob-the-hamster
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. |
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. |
Comment author: @bob-the-hamster
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
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) |
Comment author: @bob-the-hamster *** Bug bz#316 has been marked as a duplicate of this bug. *** |
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) Step 2) Step 3) Step 4) 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 |
Comment author: @bob-the-hamster All the steps I described in comment 33 are finished, marking this bug fixed. |
Comment author: @bob-the-hamster er... *actually* marking fixed. |
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) |
Comment author: @bob-the-hamster
Yes, actually, I believe oggenc has a command-line option to resample to a different frequency |
Comment author: @bob-the-hamster
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 |
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/ |
Comment author: @ziggythehamster I'm seeing the same issues with 8khz files. Odd. sox does upconvert just fine though. |
[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
The text was updated successfully, but these errors were encountered: