Support musics that contain non-normalized float samples #310

LaurentGomila opened this Issue Oct 29, 2012 · 8 comments


None yet

8 participants


Due to the float-to-int conversion in libsndfile, any float sample above 1.0 will get converted to an invalid value, which may produce cracks when the music is played.

We can avoid that by normalizing the values when opening the file, but it is incredibly slow for long musics (can take many seconds).

See this issue on the libsndfile tracker: erikd/libsndfile#16

Possible solutions are:

  • always normalize and live with the long loading times ( no way )
  • never normalize and tell people to reencode their musics if needed ( very inconvenient )
  • add a function or flag to let the user decide ( ugly )
  • internally keep float samples for sf::Music, it would have no effect on the public API ( doesn't solve the problem for sf::SoundBuffer )
Qix- commented Nov 1, 2012

Or just have a applyClip() function that performs a min(1.0, x) on each sample frame. Normalizing can cause greatly affect how a song sounds, which may upset some people.


Clamping would not work, see this: erikd/libsndfile#16 (comment)

Qix- commented Nov 1, 2012

Aha, I see, that's annoying. I wasn't aware OGG files supported float values <> 1.0.

@flibitijibibo flibitijibibo referenced this issue in SuperV1234/SSVOpenHexagon Nov 27, 2012

Ogg files need a re-record #21

kd7tck commented Mar 20, 2013

Just a future idea...
A possible fix might be to petition the xiph foundation, in order to modify the ogg standard. The new standard would include the maximum sample values +/- inside of every ogg audio stream.

@LaurentGomila LaurentGomila removed their assignment May 19, 2014

We might have other options once #604 is completed.

hsdk123 commented Jun 2, 2014

Laurent's just mentioned this in the last post, but it would be great to have this considered along with the new audio implementation 👍

@Bromeon Bromeon added the s:accepted label Jun 6, 2014
@eXpl0it3r eXpl0it3r removed this from the 2.x milestone Nov 13, 2014
@LaurentGomila LaurentGomila removed this from the 2.x milestone Nov 13, 2014
@eXpl0it3r eXpl0it3r removed the s:unassigned label Jan 8, 2015

Bump. 😁


Actually, I don't think that the new implementation makes anything easier regarding this problem. We just have more control, so we could try other strategies (like normalizing on the fly, using the current maximum).

@binary1248 binary1248 added feature and removed bug labels Oct 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment