Noise inside tuba sound
Steps:
1- Make sure you using the sf3 soundfont;
2- Open attached file;
3- Play.
Result:
You can hear a high frequency noise above the sound of the tuba. Attached the result from export to FLAC (rename tuba_flac.txt to tuba.flac).
Windows 8.1, commit 1fb21eb
Also noted in: [#32731]
See in particular http://musescore.org/en/node/32731#comment-138521
Notes:
The problem arises from the sample reconstructed by the ogg/vorbis algorithm. In the following figure you can see the original sample (blue) and the sample from the sf3 (red): inside the loop range (delimited by the green dashed lines) the compressed sample exhibits noise, which is the responsible for the high frequency "hum" (the different amplitude is due to the normalization hack which prevents integer overflow).
This noise is probably due to a discontinuity in the input sample which feeds the compression algorithm (sfconvert tool). Indeed, the input sample is padded (with zeros ? ) in order to have a dimension which is an integer multiple of 1024.
Note that this noise actually appears in all compressed samples, but due to a series of unfortunate events it is clearly audible only in the tuba (loop encompassing one single period of the sound wave).
I think I found a possible solution: we can pad with the sample loop instead of zeros; this would also make a better junction between the loopstart and loopend points in the final sample. The result from a modified sfconvert tool is shown in the following picture:
where the magenta wave is the signal coming from the sf3 files saved with the modified sfconvert tool.
As a further example, here are the results when the instrument is changed to Bass Trombone in the original file: blue is the SF2 sample, red is the SF3 sample, magenta is the corrected SF3 sample.
You can see some noise in the last period of the red wave before the green boundary.
The fix I am using is this one:
https://github.com/AntonioBL/sftools/commit/4b7f40023fa711a3303abd0489e…
1- IMPORTANT NOTE: I think I am maybe padding wrongly by 1 shift in the index, please check the loopstart, loopend and indexing if you want to merge this "patch". Moreover, I am sure I am handling all possible combinations of length of the sample, length of the new sample, and length of the loop.
(I also probably messed up the commit history by rebasing on a branch instead of master)
2- It would be maybe better to pad with loops until the end of the new sample size (mutliple of 1024); with this "patch" I am just adding one single loop after the actual sample.
| Attachment | Size |
|---|---|
| tuba.mscz | 1.01 KB |
| tuba_flac.txt | 195.03 KB |
| untitled.png | 16.1 KB |
| tuba_corrected.png | 17.79 KB |
| basstrombone.png | 17.92 KB |
Comments
EDIT:
1- IMPORTANT NOTE: I think I am maybe padding wrongly by 1 shift in the index, please check the loopstart, loopend and indexing if you want to merge this "patch". Moreover, I am not sure I am handling all possible combinations of length of the sample, length of the new sample, and length of the loop.
Are you aware of this ABL?
#21814: Playback of SF3 features loud pops
This is the most likely cause of the problem in the tuba.
It is caused by a bug in libsndfile which is supposed to be fixed when version 1.26 is released.
The developer is being very tardy in releasing this for some reason
It was thought that attenuating the samples fixed the problem, but apparently not in the Tuba.
The options as I see it are:-
1. to use the latest pre-release version of libsndfile 1.26 (released last February)
2. attempt to patch libsndfile ourselves
3. wait for the stable release of libsndfile 1.26
4. See if ABL can come up with another hack to solve this.
Maybe we should re-open #21814??
@ChurchOrganist:
Of course I am aware of that problem: guess who is the author of the analysis in the thread http://musescore.org/en/node/22086 ? :-)
And guess who proposed the "dirty trick" of changing normalization to overcome it ? :-)
This problem is an unrelated one. The problem in that case (#21814: Playback of SF3 features loud pops) was integer overflow during decompression. In this case this looks like a boundary problem in the compression/decompression algorithm. And as I am trying to point out in this thread, I would bet that it is related to a discontinuity in the wave function due to the arbitrary padding with zeros which happens during the generation of the sf3 samples.
Even if we reduced further more the amplitude of the signal (i.e. increase the correction that prevented #21814: Playback of SF3 features loud pops) this specific noise would not disappear!
This is not a bug of libsndfile as the previous one, but most probably a bug in the sfconvert tool: this noise appears in every sound sample (actually in the samples that in the original sf2 do not end with 0), but it is evident in the tuba because in this specific case the sound loop covers one single period of the wave function.
> It was thought that attenuating the samples fixed the problem, but apparently not in the Tuba.
> The options as I see it are:-
> 1. to use the latest pre-release version of libsndfile 1.26 (released last February)
> 2. attempt to patch libsndfile ourselves
> 3. wait for the stable release of libsndfile 1.26
Note: all these solution would not solve this problem, but only the other problem (#21814: Playback of SF3 features loud pops).
> 4. See if ABL can come up with another hack to solve this.
Well, I maybe wrote it in a convoluted way, but I already have one possible solution: I patched the sftool program (but, as I said, I think I have probably offset the indexes by 1) and with this patched version a new sf3 can be generated in which the boundary noise in all the samples is no more present. The "trick" I used was to pad with the sound loop instead of 0, so that the wave function in proximity of the loop boundaries is continuous and also its first derivative is continuous. This trick probably just shifts the noise to this additional oscillation in the function, which, being outside the loop, is simply discarded during playback.
I do not know the precise details of the algorithm, but if it is assuming periodic boundary conditions it may require to end with a tail of zeros. The trick I am using may prevent this tail of zeros and I do not know if this may introduce noise at the beginning of the sample.
I'm curious - I realize some are not all that happy with FluidR3 for other reasons. *Are* there other soundfonts we could/should be considering as defaults? Or even building our own by taking FluidR3 as our base and replacing certain sounds with others? I know there has long been support within the MuseScore community for GeneralUser GS, and recently people have been mentioning Arachno. I don't find either of these as good as FluidR3 overall, but maybe it's worth considering borrowing a few samples?
OK. Thanks for the clarification.
So if the loop was changed on the sample that would also fix the problem?
Incidentally I notice Werner hasn't yet merged your pull request for sftools.
Would it be OK if I forked from your sftools repository?
@Marc ultimately it would be great to have our own soundfont.
As I have said before - I'm not a fan of FluidR3 the quality of many of the samples is inferior and the sound design aspects of the soundfont are extremely dodgy.
It is pretty good as an all round workhorse, but I think probably the way forward is to develop specialist soundfonts for various requirements, so that a modular approach could be used, where the user can download the instrument sections (s)he needs.
I will stop here as I'm getting way off topic :)
@ChurchOrganist:
> So if the loop was changed on the sample that would also fix the problem?
Probably the problem would be reduced if the loop encompassed more than one period of the wave function, but some noise would still be present (thus periodically repeating during the loop, generating a false signal).
> Incidentally I notice Werner hasn't yet merged your pull request for sftools.
They were two pull request to try to adjust problems I found, but the Windows behavior is still buggy. [Off-topic] I am still investigating to pin down the cause: I *think* a bogus
zoneis appended to the zone list (which is also the cause of the crash in the xml export), but I still can't understand why it appears in Windows but not in Linux. [End of Off-topic]> Would it be OK if I forked from your sftools repository?
Please, you are welcome. This is the philosophy of github, I think.
However, I think that you should work under Linux, since as I am saying in the Off-topic above under Windows there are still problems.
Note that the other commits I accidentally put in inside this branch are not necessary.
I am not so sure discussing alterate soundfonts is off topic - after all, it's another method of fixing the issue.
Yes, you have said before you find some of the samples to be "inferior", but I still don't understand which samples or which soundfont *specifically* you find them inferior to. That's what I am trying to find out. If there is something better we could use - either as a whole for specific inferior samples - shouldn't we be considering it? That is, could we not simply replace tuba, muted trumpet, or whatever other sounds from this hypothetical "superior" soundfont, license permitting?
I suspect it might turn out to be a case where certain samples *individually*, when examined under a microscope, don't sound good. But the overall effect when actually played with real scores is still better than any viable alternative I've heard. And that might be in part because some of the things you find inferior - like the very soft attack on many instruments, which might sound realistic when listening to just one note but sounds much better than others in legato passages. But maybe I'm wrong and there really a soundfont that reallyu does work better on real world scores. If so, shouldn't we discussing that?
By inferior quality I am referring to the quality of the samples themselves, not in relation to other soundfonts.
Many of the samples in Fluid R3 have artifacts, background noise, distortion and other problems to do with actual recording of the samples themselves.
As I remarked at the time when I first opened it to solve the problem with missing notes in the violin, I was quite shocked by the recording standard of some of the samples.
It is still a considerable improvement on TimGM6mb though.
I was hoping that by now we might have had samples to use donated by the MuseScore community, but that doesn't seem to have happened yet, probably because we've all been so busy trying to get MuseScore 2 out, that the focus has been on that rather than promoting the idea that people should donate sets of samples.
The big problem is that being OpenGL V2 licenced application really any soundfont we supply with it needs a licence equivalent with that or less strict like the MIT licence Fluid R3 is issued under.
This means we have to be able to guarantee that the recorded samples making up the soundfont also have a licence granting the same freedoms.
This is not the case with nearly all soundfonts many of which contain samples of unknown origin with the potential for law suits should the original owners ever find out they were being used this way.
Hope that makes it clearer Marc :)
Proposed PR for the sftool:
https://github.com/wschweer/sftools/pull/5
I should have corrected the off-by-one error, and now the PR is properly rebased.
Note:
The sf3 soundfont must be re-generated after this patch.
The previous PR was introducing problems in non-looping samples (e.g. drumset samples).
I found a better solution: do not pad the sample :-)
Proposed (and working also for non-looping samples) PR:
https://github.com/wschweer/sftools/pull/6
Of course, the sf3 soundfont must be re-generated after this patch.
Fixed since a1a14fe183
Automatically closed -- issue fixed for 2 weeks with no activity.
Actually, I use a soundfont that used to come with the free Finale Notepad. Whether the score is for orchestra, concert band, string quartet or what have you, it's pretty much unsurpassed across the instruments. I'm wary of the possibility that it might be copyrighted or something, or I would attach synthgms.sf2 to this post.
Huh, I just tried that out. It's definitely not bad for its size - comparable to GeneralUserGS I guess, but still not really up to the standards of FluidR3 or other larger soundfonts such as Timbres of Heaven to my ears.
Are you sure you have the same one? There are soundfonts on the internet called SynthGMS that aren't actually the same thing. The SF2 file should be 35.8 MB.
Yes, that's the one - the one I grabbed from my copy of Finale Notepad. The size is comparable to GeneralUserGS, and to my ears the quality is roughly similar, although at first blush I'd rate synthgms better overall. But FluidR3 is over 100MB (the sf2 version anyhow), Timbres of Heaven over 300MB, and these are both *very* noticeably better to me. As are some other non-GM soundfonts of similar complexity (size is relative when talking non-GM, as the number of isntruments is not constant). It's not *necessarily* the case that bigger = better, but it does generally mean longer samples, more velocity split points, etc, and these things really do translate quite readily into differences you can hear.