Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Support musics that contain non-normalized float samples #310

Open
LaurentGomila opened this Issue · 8 comments

8 participants

@LaurentGomila

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-

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.

@LaurentGomila

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

@Qix-

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
Closed

Ogg files need a re-record #21

@kd7tck

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
@LaurentGomila

We might have other options once #604 is completed.

@hsdk123

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
@binary1248
Owner

Bump. :grin:

@LaurentGomila

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.