Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SF4 (FLAC)? #16

Open
mxmilkiib opened this issue Jan 2, 2020 · 8 comments
Open

SF4 (FLAC)? #16

mxmilkiib opened this issue Jan 2, 2020 · 8 comments

Comments

@mxmilkiib
Copy link

mxmilkiib commented Jan 2, 2020

Might FluidLite see support for SF4 banks with FLAC audio?

@mxmilkiib mxmilkiib changed the title SF4 ( SF4 (FLAC)? Jan 2, 2020
@divideconcept
Copy link
Owner

Interesting, didn't know SF4 existed. Do you have a link to some doc/example ?

@mxmilkiib
Copy link
Author

https://github.com/cognitone/sf2convert is my reference so far. SF4 seems more fitting in a professional audio context than SF3, i.e. lossless compression over lossy, though I guess the user experience of downloading and storing large files can be said to be a disadvantage by some.

@davy7125
Copy link

davy7125 commented Jan 6, 2020

It's a pity that developers are currently designing their own updates on the sf2 format without more discussion. Here is a bit of history:

  • At first we had the sf2 format, designed by the EMU company. First version 2.01 and then 2.04. Everything is well documented.
  • Then MuseScore introduced the sf3 format, which is basically the same than the sf2 version 2.04 but including compressed samples (with loss). Another extension .sf3 is here wise, since we are dealing with a file that doesn't have exactly the same purpose. The compression allows the file to be more easily embedded, but we will not use it for applying modifications because of the quality that has already be lowered. This is a file used for production, not editing. So the other extension is wise but this is the beginning of the mess.
  • Now we have the sf4 extension containing a lossless compression. It is great that it would be like sf2 with a half size for the same quality. But to me the sf4 IS NOT JUSTIFIED since sf2 would have the exact use of the sf2 format (for editing). Moreover, the sf3 itself would be able to include FLAC format according to what I saw.

So I'm not sure this is the right place to speak about it but if developers are reading this post please consider a deeper rework on the sf2 format instead of providing sf_WHATEVER_YOU_THINK_OF extensions:

  • gather defects on the actual sf2 specification v2.04 (I could write a part of it)
  • gather all updates that would be interesting to have
  • write the sf2 specifications version 3.00
  • THEN (only then) provide sf2 and sf3 extensions, the first one being either compressed or not but no loss in all cases, the second one being compressed with loss.

Open source must not be synonym to disorganization. The strength of sf2 is its open and documented format, don't mess it.

@trebmuh
Copy link

trebmuh commented Jan 6, 2020

Sounds wise. Thanks @davy7125 .

@davy7125
Copy link

davy7125 commented Jan 7, 2020

Here it is: https://github.com/davy7125/soundfont-standard-v3
I'll try to spread the idea.

@mxmilkiib
Copy link
Author

mxmilkiib commented Jan 7, 2020

It's a pity that developers are currently designing their own updates on the sf2 without more discussion.

This issue is not regarding SF2, it's regarding SF4.

Another extension .sf3 is here wise, since we are dealing with a file that doesn't have exactly the same purpose.

If you believe that for SF3, I'm confused as to why you can't believe it for SF4.

This is a file used for production, not editing.

Personally I wouldn't say that lossly samples are fit for production, but that's just a subjective take, plenty of folk are happy with some aspects of a lofi aesthetic.

As far as I see it, SF3 exists because users want their sample banks to a) download quicker, b) take less drive space, and c) (in some cases) if lossy, be a preview version of a lossless version.

But to me the sf4 IS NOT JUSTIFIED since sf2 would have the exact use of the sf2 format (for editing). Moreover, the sf3 itself would be able to include FLAC format according to what I saw.

The crux of the issue. Maybe I am misunderstanding the situation. There are two rationals I have for raising this issue;

a) I don't believe there any expectation from developers of SF2 (or SF3) tools that sample format used would be other than the original.

Your argument that "developers are currently designing their own updates on the sf2 without more discussion" kind of applies to yourself for your adding FLAC support in SF2 to polyphone. I totally don't begrudge you for doing so, and I'm glad we are having this discussion :)

Maybe FLAC in SF2 is already more widespread? Might you be able to fill in the history?

b) Major usability issues - who is to tell if a SF2 player supports FLAC SF2s? In my perspective, you want such file compatability so be incredibly obvious to users. This I see as a rational as to why .sf3 was created.

Indeed, who is to tell what SF2 is what? How to have a WAV and compressed FLAC SF in the same directory? The solution, if a file extension is not used, would be "drum_samples_jan2020_wav.sf2" and "drum_samples_jan2020_flac.sf2", which I think misses a trick.

(Maybe a compromise of "drum_samples_jan2020.wav.sf2", "drum_samples_jan2020.flac.sf2", but that might be a case of attempting to close the stable door after horse has already bolted on that specific point.)

The strength of sf2 is its open and documented format, don't mess it.

I thought SF2 was a trademarked format, which is part of the reason developers prefer SFZ (i.e., #sfzformat on Freenode has developers from multiple SFZ projects in it).

@davy7125
Copy link

davy7125 commented Jan 7, 2020

My point is that a deeper update of the sf2 format (currently version 2.04) - that could automatically include a FLAC compression for instance - could prevent the need of an sf4 format and further research on soundfont compression. But this is a bigger work than just slightly changing the data storage and a letter in the extension. After reading your message I tend to think that the best situation would be to have:

  • file.sf2 that would contain raw data,
  • file.ogg.sf2 (actual sf3),
  • file.flac.sf2 (sf4?).
    This is justified in that internally data is stored differently, but apart from this, the format itself is the same. Nice suggestion :-) And people who take care of the data compression will recognize it.

Regarding the FLAC support into Polyphone, this is just for importing samples. When the soundfont is saved, this is raw data inside. Until now I have never seen a soundfont containing a FLAC sample.

I don't know to what extent the old sf2 copyright decided for the sfz creation. According to what I saw it was first the question of being able to read the parameters on a text editor otherwise maybe they would have improved the sf2 format already... Now I'd like to do it so that sf2 and sfz would be almost equivalent, the difference being on how the files are saved.

@nick87720z
Copy link

Just curious, what if FluidLite, compared to full fluidsynth, had support for separate audio file loaders, which in turn could support any possible format. This way it could not need to load format support libraries into main process.

Btw, (sorry if it's offtopic) another good sample format, that came to my mind - opus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants