Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Alternative fix for #271, no slowdown #341

wants to merge 1 commit into


None yet
6 participants

This method adapting for input level, no slowdown.

Been a while since I've done some DSP, but wouldn't you determine the max scaling value over the whole track first rather then determining it "on the fly" while scaling already? E.g. the values in raw could be [5, 10, 15] you'd scale the first value using 5, the second one using 10, etc., resulting in [32767.0, 32767.0, 32767], because the maximum changes every iteration? Or am I missing something right now and this is working differently and/or intentionally that way?


Marisa-Chan replied Jan 24, 2013

Ah, okay, so it's essentially a "lesser evil" approach? Cause it should work fine once the maximum has been reached.


Marisa-Chan replied Jan 24, 2013


LaurentGomila commented Jan 25, 2013

Shouldn't the solution (this one or another) be implemented in libsndfile directly?

If plans of libsndfile for excellent quality then no. If yes then it's will be hard work(not my) for implement it in all sound decoders.

However http://www.mega-nerd.com/libsndfile/api.html#note2 this tell for us that this "bug" won't fixed and hint for using same data types.


LaurentGomila commented Jan 26, 2013

Too bad... :(


MarioLiebisch commented Jan 27, 2013

Maybe add a new CMake flag to decide between "accuracy" and "speed", so it's possible to pick between both implementations? A runtime setable flag would be another option, although I'm not sure something like that would be needed.


LaurentGomila commented Jan 27, 2013

I don't like compile-time options:

  • they create different variants of the SFML libraries
  • if you change something you must distribute your own version of SFML, which may conflict with the official ones
  • most users won't recompile SFML, and just use the distributed official binaries

I agree with Laurent, this is bad way. But making many runtime hacks - it's not good too.

In my vision make two functions for reading one for float-point formats (SF_FORMAT_DOUBLE, SF_FORMAT_FLOAT, SF_FORMAT_VORBIS) and normal integer. By this method we receive exactly data without slowdowns and additional "blackbox" conversions.


LaurentGomila commented Jan 28, 2013

This would of course be the optimal solution, but it is not compatible with the public API -- don't forget that the sample type is directly exposed to the user (in sf::SoundBuffer). And I'd like to expose only a unique sample format.

However, maybe I could keep sf::Int16 in the public API, and use floats internally for sf::Music (ogg/vorbis audio files will most likely always be musics).

Sometimes sound fx in ogg too, may be my solution not bad?


LaurentGomila commented May 19, 2014

Just mentioning #271 to have a link to this PR there.

@LaurentGomila LaurentGomila removed their assignment May 19, 2014

@Bromeon Bromeon added the s:accepted label Jun 6, 2014


eXpl0it3r commented Jul 8, 2014

Do still want to investigate this further with libsndfile getting refactored out at one point (#604)?


LaurentGomila commented Jul 8, 2014

The problem will still be there when we use libogg/libvorbis directly, but the fix will most likely be different anyway, so we can close this PR.


eXpl0it3r commented Jul 8, 2014

I hope we'll be able to use some of the ideas once we get to solve similar issues with libogg/libvorbis.

Otherwise I'll close this pull request. The original issue #271 has already, but could be reopened if someone wants to discuss things further.

@eXpl0it3r eXpl0it3r closed this Jul 8, 2014

@eXpl0it3r eXpl0it3r removed this from the 2.x milestone Jul 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment