Slow music loading

[eigen]

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 tutorial for building.

Any ideas? Has sf::Music openFromFile been recently twiddled with?

[Laurent]

The only thing that changed recently is this commit.

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

[eigen]

That totally fixed it! I guess that's actually bad news for you ..

[Laurent]

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)?

[Nexus]

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).

[Laurent]

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].

[Nexus]

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?

[eigen]

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.

[Laurent]

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.

[Laurent]

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.

[Nexus]

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

[Laurent]

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.

[Nexus]

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

[eigen]

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.

[Laurent]

This is really ugly, I can't add such a function

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.