SFML community forums
Help => Audio => Topic started by: eigen on October 26, 2012, 06:14:25 pm
-
So last night I updated my game on Windows 7 from the SFML 2.0 RC version to the latest git snapshot. Most of it works but now music loading takes forever. Previously I wasn't even noticing the loading screen as it was so brief, but now it takes 10-15 seconds easily. That's unacceptable.
I'm using the openFromFile(); method. As I understand, that doesn't load the whole thing into memory but streams it instead. But if I log each file I see they each take considerable time. It almost feels like they're all read into memory which is odd, as sf::Music wasn't supposed to do that. What further makes me think that is the case is that longer files take longer to load, which shouldn't be the case with streaming ...
I could post code but I don't see how that helps, it's all very standard. The same code acts differently with different SFML builds.
My music files are OGG.
I'm using this (http://sfmlcoder.wordpress.com/2011/06/16/building-sfml-2-0-with-mingw-make/) tutorial for building.
Any ideas? Has sf::Music openFromFile been recently twiddled with?
-
The only thing that changed recently is this commit (https://github.com/SFML/SFML/commit/6e81dabeda4157361a30b600867371d7d85fbc7c).
Commenting out line 267 (sf_command(...)) should solve the problem. This function computes the scale factor to apply to float values to normalize them, so I guess it iterates over all the audio samples of the file to find the min/max values.
If that's the case, this is indeed very annoying :D
-
That totally fixed it! I guess that's actually bad news for you .. :-\
-
I got an answer, and I was right about this function.
Unfortunately there is no workaround, the only clean solution would be to keep a floating point format instead of converting everything to short integer. Which is of course not compatible at all with SFML :)
So... what's best? Slow loading (this call enabled), or cracks during playing (this call disabled)? :-\
-
Do these crackles only happen since a certain time, or in unfortunate circumstances? Because in my game Zloxx II (which uses SFML 2 shortly before the new naming convention) the .ogg files play fine.
I once had some crackle, but that was fixed after I updated the two audio DLLs (OpenAL and libsndfile).
-
The cracks appear when the ogg file contains float samples with a value greater than one. The conversion to short integer expects the values to be normalized, therefore values greater than 1 overflow the max short value and produce corrupted samples.
So it happens only with those files that have samples > 1.
The sf_command(...) function finds the greater sample (maximum float value) in the whole file, so that the library can normalize samples in range [0 .. 1].
-
Yes, that's what I have seen in the GitHub tracker, but it is better to have a short summary in this thread :)
I wanted to ask why this issue popped up so recently? Was it just luck/nobody cared or did you use another technique in the past?
Anyway, I also think such long loading times are not acceptable. The files can be normalized once so that they work, but long loading times are inevitable and a major annoyance. Wouldn't it be a possibility to add normalize functionality somewhere in the lower-level sound API (like sf::SoundBuffer), so that people could correct that and store the result to a file?
-
Funny, I haven't noticed any cracking either but then again they haven't been overly amplified. All is in normal range. Either way, this option should be configurable somewhere. If your sounds have been properly produced, there really are no issues so you don't need it. Instead of just normalizing, couldn't you just clip those that are > 1 ? Clipping isn't nice but depending on the sound may not even be noticable by most people and is a significantly faster process.
-
I wanted to ask why this issue popped up so recently?
The usual answer was "try to reencode it with another software", and I guess it was enough most of the time. Until someone took the time to investigate and find this bug in libsndfile ;)
Instead of just normalizing, couldn't you just clip those that are > 1 ?
Sounds like a good idea, I've forwarded it on libsndfile's tracker.
-
About clamping the values:
Your proposed solution works very poorly for sound files where the float values are in the range [-32768.0, 32767.0].
Files like this do exist in the wild.
-
I don't know if you have seen it before:
Wouldn't it be a possibility to add normalize functionality somewhere in the lower-level sound API (like sf::SoundBuffer), so that people could correct that and store the result to a file?
It would require users to adjust the music manually, but this happens only once, and does not punish all the people who have their music inside correct bounds ;)
-
Wouldn't it be a possibility to add normalize functionality somewhere in the lower-level sound API (like sf::SoundBuffer), so that people could correct that and store the result to a file?
It can only be an argument of load/open functions, because the float-to-int conversion occurs during loading. And I don't like this idea anyway, it looks like a hack; SFML should be able to handle this automatically, it's just currently limited by its design.
-
Okay, I agree it's an annoying technical detail. Apparently the only option would be to use floats...
Do you already know if you revert to the crackle bug? It would be a real pity if SFML 2.0 had unavoidably long loading times for music :-\
-
I don't think you should force this on the developer/user. If one knows what he's doing and his files are okay, there's no need for it and there should be a way to disable the unneccesary conversion. Otherwise I'd have to comment out the call and build the source myself everytime a new version comes along.
Something like sf::Music::enableOggVorbisNormalization(false) maybe.
-
This is really ugly, I can't add such a function :P
I guess I'll revert to the cracking bug, and tell people to reencode their files in this case :(
Maybe I could use float samples in sf::Music (when needed); since it's hidden, it would have no effect on the public API. But the bug would remain for sf::SoundBuffer.
-
I've created a task on the tracker:
https://github.com/SFML/SFML/issues/310
-
What is the reason why int16 is used instead of float?
-
What is the reason why int16 is used instead of float?
It is the most standard and widely supported format. It takes half less memory than float. And it's probably easier to work with.
Oh, and float format is an extension, it's not available in the OpenAL core API. So its not guaranteed to be supported everywhere.
-
Was the change ever reverted? It doesn't seem so to me.
I just noticed that opening a music (ogg) from a stream took AGES (it's 15.8 MB in size, takes about 7 seconds to load). I analyzed it, and indeed the whole stream is being iterated over before "openFromStream" is done and the application continues. This practically nullifies the "instant play" advantage that streaming offers.
While cracking .ogg files are something a developer can fix if he informs himself about the supported formats, people who are not affected by that issue now suffer from immense loading times. Besides, you only need to "fix" / convert your .ogg file once to resolve the issue for good, but the way it is now everyone needs to wait every single time the application starts. I think a bit of responsibility can be left to those who opt to use .ogg files. This is definitely not worth the cost.
-
I completely agree with above.
-
You're right. I've disabled it.
-
Thanks!
I hope a suitable solution can be found for that floating point format at some point as well.
-
I wanted to ask about this ( I was about to post here on the forums ). Because about 4-6 months ago I used sf::Music and it worked pefectly ( couldn't hear cracking ) but now it takes SECONDS to load/stream. What is the current status?
How do VLC and other players stream their music/videos without these problems and how do I ...uh what do you call it reecode the audiofiles.
-
I wanted to ask about this ( I was about to post here on the forums ). Because about 4-6 months ago I used sf::Music and it worked pefectly ( couldn't hear cracking ) but now it takes SECONDS to load/stream. What is the current status?
You're right. I've disabled it.
Which means it's already fixed in the latest commit on GitHub (thus if you want it you have to download it and compile SFML on your own).
How do VLC and other players stream their music/videos without these problems and how do I ...uh what do you call it reecode the audiofiles.
I'm not sure where this questions should lead to...
Audio stuff is a complex topic and most of them use either some specific set of libraries or write their own thing. Since VLC is OpenSource you're free to look at their code. ;D
-
How do VLC and other players stream their music/videos without these problems
They most likely play the audio samples in their native format, instead of trying to convert them to a different one like SFML does.