Dynamics not recognised in wave output

• May 1, 2017 - 22:44

Well, sometimes parts of the score's dynamics are recognised and parts are not. I tried applying the dynamics system-wide, to the staff, to the part and the output varies, but is inconsistent.

It's very annoying. Does anyone know the reason why the dynamics do not auto-output to wave in the way they are in the musescore playback?

For the record these are "ppp" indications.


Comments

In reply to by Roger v.d Velde

Could be anything - hard to say. For instance, if you have customized your palettes, your dynamics might indeed be special. Or if you have customized your preferences. Or if all your scores are created from the same template and issue is found there, not in MsueScore itself. Impossible to tell without precise steps to reproduce the problem. And that means posting a sample score to demonstrate the problem, and I guess a list of SFZ soundfonts we need to load in order to see the problem.

In reply to by Roger v.d Velde

Well you already mentioned using SFZ soundfonts, so that's at least one thing you changed from the defaults. Anyhow, again, in order to investigate, we need to be able to reproduce the problem, and that means having a sample score and precise steps to reproduce the problem. Otherwise we can only guess at what might be happening.

In reply to by Marc Sabatella

No, it does not mean having a sample score, this is not source code. All the scores made on musescore are made using the same fixed methodology; that goes for everyone. The option for adding sfz instruments is not a 'hack' it's supposed to be part of musescore's normal usage.

The simple fact is this: the dynamics on sfz instruments work in the programme, but don't export. I understand that the sfz support is not yet 100% and I accept this. I think perhaps that the shaky support for sfz is best probably withheld until musescore can support it properly.

What I don't accept is the harping on about how people need to see a score, as if me clicking on 'pp' and adding it to a bar is any different from anyone else doing so.

In reply to by Roger v.d Velde

See my comment above. Save to Score is not needed in 2.1 (at least, it is no longer relevant to audio export), and in any case, it had nothing to do with dynamics. It was formally needed to get MuseScore to use your preferred sound font at all. If you omitted that step, you'd get audio from the default sound font instead. But dynamics would be intact. Feel free to review the steps to be sure, but I think you will find this is not the key.

It's much more likely to be what lasconic guessed - normalization that increases the overall volume while still preserving the relative dynamic changes. That's easy enough to check - just try a score with both pp and ff in it.

In reply to by Roger v.d Velde

I know it must *seem* like this would apply the same to everyone, but the simple fact it, it doesn't. Not all scores made using the same fixed methodology, there are *lots* of differences. Whether you apply a dynamic by double clicking or drag and drop or copy and paste; what voice the dynamic is applied to; whether the dynamic is applied to a staff, part, or entire system; whether multiple staves are involved; whether the notes those dynamics are applied to have their own velocity settings; whether you are using a custom palette; what audio settings you have made in your preferences; what specific soundfonts you are using; what other synthesizer settings you have made; what Mixer settings are involved; and so on, and so on. There are *tons* of variables that could possibly be involved here. Any one of those could possibly explain why you are seeing a problem that no one else seems to be seeing. Of course, it could also be something unique to your system, not your score - something about your OS version, audio device drivers, shared / dynamic link libraries, etc. Or something about how you are doing the export.

In any case, the problem you describe is *not* the "simple fact" you describe. Hundreds if not thousands of other users have done this with no problems, and I just tried it myself to be completely certain. It works just fine for me. *Something* is different about your score, your system, and/or your methodology, and that something is why you are seeing a problem that no one else is.

So, again, in order to help resolve this problem, we need to be able to reproduce it, and right now we cannot. That is why we are asking for your assistance. you are the only person seeing this problem, so you are in a unique position to help us reproduce it and fix it.

A sample mscz file would really help but we can try to guess.
Audio export applies normalisation (https://en.wikipedia.org/wiki/Audio_normalization). So, depending on your dynamics in the rest of the score, it's possible that your ppp are louder indeed. If it's annoying you can export to MIDI and do the rendering in another tool, or you can patch MuseScore to add an option to not normalize. Happy to review your code contribution.

In reply to by Nicolas

Good point. If a score has no *change* in dynamics - only a single dynamic marking at the beginning of the score - it will come out uniformly loud (regardless of what the specific dynamic marking is) because of normalization. The *relative* dynamics within a score are honored, but the overall level will be set so the loudest passage - even if only "p" - is reasonably loud. This is indeed "normal"; it's done in most professionally recorded music.

In reply to by Marc Sabatella

How can I fix the audio "normalization" on the exports. It's been a few months since I started using MuseScore 2.1 and I never had this happen, but now, all of a sudden, no matter what dynamic I put into the beginning of the score, when I export it, it's way too loud! I tried everything, but I can't fix this. I know that the audio normalization is a feature and not a bug, but it's driving me insane! This is a work in progress of a score I'm doing.

In reply to by Leonardo Garcia

If you wish to reduce the volume of an audio file, there are any number of programs that can do this. Audacity is a popular free / open source choice. But note, normalization is called rhat for a reason :-). A file that is reduce to less volume will sound quieter than other audio in your system as well as those out might share the audio with. So "normally" you would not want to reduce this.

In reply to by Leonardo Garcia

There's a trick I used to do this :)
But I don't know if it's useful for you.
Add an instrument, select "ocarina" ("human whistle", "sine wave" or "flute").
Add three measures to the beginning of the piece. (to prevent reverb)
Put a half duration note on the first measure. (According to the G clef, the "B" note on the third line is ideal.) //approx: 1Khz tone.
Add "fff" dynamic (on this instrument.)
And export it.

Then you can cut the gap at the beginning of the exported audio file . (with an audio editing software, like Audacity).

In reply to by Leonardo Garcia

Leonardo,

I suggest you do this: get Audacity (free) and don't export audio via MusesScore Export option. Just play the score inside MuseScore (using the "play" button") , while (at the same time, in another window), record the output via Audacity "Record" button.

I too got frustrated by the normalization generated via the Export option. Specially, a side effect of normalization I didn't like is the impact over the note attacks. I'm very satisfied using the above method for all my recordings, and you can always later apply normalization if you need (and a lot of other effects) via Audacity. The MuseScore synth render, when played inside the program itself, sounds excellent.

In reply to by mdi1972

In that situation, it seems it would be a lot easier to simply revert the normalization using Audacity. If you record your output channel, you have to be sure to not even generate a mouse-click sound or anything else.

Export from MuseScore.
Open tracks in Audacity
Run "Normalization" in Audacity on the tracks and set desired levels (for example to -6dB)

You can even start by sliding the tracks gain levels to first figure out the desired relational volume. But at least you don't have to worry about interfering sounds from other processes that way.

In reply to by jeetee

Well, jettee, once you Export, at least in my case, the normalization process is irreversible. Even if I later tweak in Audacity, trying to reverse the process, I feel the net result is not the same. Some effects get lost, unless I record the original output synth.

I think that simply taking care of any unwanted pops and clicks, and selecting the correct audio devices and synths in Audacity, would be enough. In my case at least.

In reply to by mdi1972

Normalization is nothing more than increasing volume, and that is certainly reversible. Perhaps you simply weren't reducing it enough? Results should in principle be identical except that as mentioned, recording the audio in Audacity should generally result in worse quality and be more dangerous if other sounds interfere.

If you are finding a case where the results from reducing the volume in Audacity do not do what you think they should, then please attach the score you are having trouble with (and say what soundfonts you are using) so we can see if perhaps there was a glitch in the normalization, or maybe a bug in Audacity.

In reply to by Marc Sabatella

Hi Marc,

I explained the issue with some detail in an older post (https://musescore.org/en/node/126031 ). The normalization applied to the Export in MuseScore it's the same process applied when uploading scores to musescore.com - at least using the default Fluid R3 Mono soundfont.)

Nicholas explained further, that the note attack was a subproduct of the normalization process. Well, I don't know, but I think it's not just about reducing volume levels, as you said.

I have sent you a message with a secret link to the score cited, as it's no longer publicly available (I made it "private" time ago). You can check that the audio of that score (directly recorded from Musescore) available at https://clyp.it/0s0axcwi , that specially after bar 21 or so (quarter notes-rest, etc.) the attacks are way much softer that the ones in the (normalized) MuseScore Exported WAV (or musescore.com playback) output.

What I would like to know is why you think that recording directly MuseScore playback via Audacity, would result in a poorer quality. In Audacity you can record the internal synth, driven by MuseScore in this case, at any lossless bitrate (I record always to WAV or FLAC), and it will not add any artifacts or click if one takes a minimal care during the recording.

In reply to by mdi1972

Peak Normalization is a really simple gain leveling in which you look at how loud the highest peak is, and then perform a volume increase on the whole soundfile so that that Peak now ends up at a given level (usually 0.0dB).
If everything is 'louder', then indeed so is the attack, making you experience it as more pronounced. Even though relatively speaking the attack volume level still hold the same ratio to the rest of the volume.

Reducing the overall volume (in case: normalizing to an alternative peak level) is exactly the reverse process. MuseScore doesn't do anything special for attack portions of sound before/during its normalization.

In reply to by jeetee

Jeetee, I'm sending a secret link to you (too) of the score for you to compare (to compare with the recorded audio as pointed in my post) . The environment (one year ago) for the recording of the score was: Musescore 2.0.2, stock FluidR3 Mono soundfount loaded, default synth parameters in the Synthetiser settings. The recording was made using the "Atube" recorder (since some time ago, I'm using Audacity instead), saving the recording to a 320 Kbps MP3 file, and then uploaded to "clyp.it". The sound you can hear in the clyp.it link provided, is exactly the same sound as heard using the Play button in my MuseScore 2.0.2.

If you manage to get the same sound via reversing the Export normalization, please, tell me.

In reply to by mdi1972

It sounds exactly the same to me. I listened closely to the playback form MuseScore 2.1 on Windows at that spot, compared it to the sound on musescore.com as well as to the sound from audio I exported myself, and they are all identical (once I adjusted for volume).

However, the audio file you sent me a link to privately does sound different. Sounds like it might have been created with either a different synthesizer settings, or maybe a different version of MuseScore. Because indeed, the attacks are very soft and gradual, very unlike how it sounds within MuseScore 2.1 or on musescore.com or in the exported audio.

So is it perhaps that the audio file you are comparing to was generated differently - with an earlier version of MuseScore perhaps, or a different soundfont, or had some processing applied?

In reply to by Marc Sabatella

Hi Marc,
No, the audio was generated just recording the playback (MuseScore 2.0.2, not 2.1, as said), with standard Fluid synth settings) with no postprocessing.

Don't bother, once I have some time, I'll assemble one case with another score, and post it here (the score plus the audio playback, etc.). I did understood that the normalization shouldn't touch the attacks so greatly (for this case), but, well, apparently it seems the case.

As said, let me recheck/document all (I'm thinking that even the "Sound" synthetiser settings at Windows level would be a factor for this) and assemble a clear case for this. Thanks for the help

In reply to by mdi1972

Ah, in that case it seems quite likely that in fact you are hearing a 2.0.2 vs 2.1 difference and not anything to do with normalization at all. There were indeed changes made that could be affecting this, some of which were intentional, others not. Some of the unintentional changes have already been fixed for 2.2, you might try downloading and testing a nightly build to see if it's more like you expect.

In reply to by Marc Sabatella

Marc, and all the rest interested,

Nothing to do with normalization. It all boiled down to a setting in the Windows-level "Sound" dialog ("Sound" ->Audio device (IDT High definition>->"Play settings"->Signal Enhanced effects" (a checkbox). So it appears very specific or dependent on the Windows version and the special effects available for the device (I'm using Windows 8 , a HP Pavillion laptop (Core i3 processor, 6 Gb RAM) , that has a internal audio device ("IDT High Definition Audio")

If I disable that checkbox: the soft attack dissapear from the playback inside MuseScore, simply.

If I reenable it, it appears again.

And it works only when Playing - nothing to do with the "Export" function -- there, it seems that, because that "audio enhancements" checkbox is only available in "Sound" ->Audio device (IDT High definition>->"Play settings" , not in "Sound" ->Audio device (IDT High definition)->"Recording settings" , then perhaps thats a reason explaining that the MuseScore Export' generated audio (.wav export in my case) don't get the benefit of this "enhanced audio" benefits.

I'm sorry that at this moment I can't upload print screens annd the sample, because I'm now at work - but tomorrow, I will edit this post, attaching the sample and some print screens with my settings and Windows Sound settings.

In reply to by mdi1972

Wow, that's an fascinating and unexpected twist - great job tracking that down!

I'm not familiar with this option and can't find anything like it on my system, so I can't test this out. I wonder if it is somehow connected, though, to the outstanding issue we do still have where certain sounds on certain systems seem to have harsher attacks on 2.1 versus 2.0.3.

In reply to by mdi1972

I realize these settings are fake bass influences and cause some oddities for the sound, I keep it all closed for years.
Perhaps for this reason I can not hear the attack problem (no matter how much I try)!

And yes, these settings do not affect the direct export functions of software such as "XMPlay", "midi to MP3 Converter" or "MuseScore". And if you export it and send it to someone else, They will listen to a different-mixing from what you hear in your headset.

This is another reason to keep it closed.

In reply to by Ziya Mete Demircan

I keep it open to get the added benefits :-D . I'm attaching some print screens of my settings at the Windows level for the embebbed IDT audio Codec, the MuseScore fluid synth settings

@Marc, I tested the latest available 2.2 nightly, and I think it behaves the same (the attacks, comparing with 2.0.2.) I don't perceive much difference between the FluidR3 Mono on 2.0.2 and that 2.2 nightly, regarding specifically the attacks (of course, with the IDT audio enhacements disabled) - but I didn't had time to rehear and test further (and I'm talking in any case only about the "Strings" instrument!)

Using another computer, a desktop HP Prodesk computer with an embebbed Realtek High Definition audio, and using various settings - I could not reproduce the IDT "benefits". I figure , to summarize, this is very dependent of the driver capabilities.

Attachment Size
Test1.mscz 16.01 KB
capture1.GIF 138.06 KB
Captura0.GIF 87.78 KB
Captura2.GIF 140.71 KB
Captura3.GIF 87.24 KB

In reply to by Leonardo Garcia

To further clarify: export still did normalize, but because you have now introduced a dynamic range including a triple forte, the peak of that sound before normalization is already very close (if not on) the 0dB level. Therefor normalization has almost nothing to do.

In reply to by Leonardo Garcia

Right. Sounds like maybe the meaning of normalize isn't clear yet. This is what it means:

Normalizing a sound recording means examining it, finding the loudest spot, and then increasing the overall volume of the entire recording so that the loudest spot on the recording is as loud as everything else on your system. This is the way virtually every piece of recorded music you have every listened to is produced; it's pretty universally standard in the music industry. So the loudest part of one recording will be as loud as the loudest part of another recording. If your particular recording happens to all be the same volume - like it's all marked "ppp", this means the loudest part is the whole thing, so the whole thing will be made as loud as other music on your system. But if your pieces has some sections "pp" but others "ff" - like most music - then the loudest part will already be as loud as it needs to be, as noted. So normalizing won't change anything.

Do you still have an unanswered question? Please log in first to post your question.