Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Support musics that contain non-normalized float samples #310

LaurentGomila opened this Issue · 8 comments

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 )

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)


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

Ogg files need a re-record #21


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

We might have other options once #604 is completed.


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

@Bromeon Bromeon added the s:accepted label
@eXpl0it3r eXpl0it3r removed this from the 2.x milestone
@LaurentGomila LaurentGomila removed this from the 2.x milestone
@eXpl0it3r eXpl0it3r removed the s:unassigned label

Bump. :grin:


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.