What determines the volume of .mp3 files exported by MuseScore?

• Jan 9, 2015 - 21:53

I'm trying to balance the overall volume of .mp3 files exported from MS with those from other sources, so that there are no major track to track volume changes when they are burned to a music CD.

I could go through the whole score and change every dynamic command, but that would be pretty tedious. I notice that moving the "vol" slider in the View>Synthesiser window not only changes the volume but also enables the "Save to score" button; so I hoped clicking that button might have caused the "vol" slider setting to be reflected in the volume of the exported .mp3, but it isn't.

I'm left wondering what does determine the overall volume of the exported file, and if there is some way of controlling it?


Comments

Loudness for playback is handled within MuseScore by using the dynamics palette (or keyboard shortcut L) to place a text marking, like fff (very loud), into the score.

If you are making a CD of audio from different sources you need to 'normalize' the tracks. This brings the volume settings of all the tracks in line with each other, so that when you listen to your CD, you won't have to keep adjusting the volume on your CD player.
Any decent burning software (Nero comes to mind) used to create a CD should have a normalize option available.

You can also use a program like Audacity where you can tweak each file, then when you are happy with the overall playback volume of all the files, you can export all as .mp3 (already normalized) - then copy the bunch to CD without using the burning app's normalization routine.

Regards.

In reply to by Jm6stringer

Thanks for the reply. I realise I could use Audacity, but I was being lazy and looking for an easier option :)

I have around 500 hymns used as accompaniment for congregational and choir singing in my local church - they were scored using Sibelius; by consistent use of the dynamics for each hymn, the .mp3 files produced from them are all pretty well balanced. I was trying to get the MS .mp3 exports to match, without me having to do a lot of "post-processing" work!

Now you've confirmed the MS synthesiser "vol" slider doesn't/shouldn't affect the .mp3 export, I'll tweak the dynamic text markings to achieve balance. Once I've got it right, I'll create a template that I can use with all subsequent hymn scores.

In reply to by Steveeh

FWIW, running a "normalize" operatiion in Audacity is a *lot* easier than individually modifying all dynamic markings in all scores. Especially since you can do it in "batch" mode. Create the normalize action, then you can run the whole 500 files through it at once. Whole process would take only minutes. Whereas I can't even begin to guess how many days of non-stop would would be required to adjust dynamics manually in 500 scores.

In reply to by Marc Sabatella

The 500 MP3 files I have are already "normalised". They were generated using Sibelius 1.4 to score each hymn, and then played through a sound card loaded with my own soundfonts. Because Sib 1.4 doesn't export MP3s directly I used Audacity to record the sound, normalise it, and save as an MP3.

One of the attractions of MS is that I can export MP3 directly without having to go through the "Recording" process. I thought I could avoid any need for "normalising" if I found out which MS dynamics (mp, pp, mf etc) produce the required level directly in the exported MP3 files, and then used those dynamics in future hymns that I score.

But thinking about it some more, the output level might still be variable - even with the same dynamic - for example depending on the number of notes being played in a chord. So perhaps Audacity's "normalisation" is still the way to go.

Thanks for the help and advice.

In reply to by Steveeh

Maybe there's another approach...

Since you already have 500 .mp3 hymns scored using Sibelius and you wish to find a way to 'normalize' the volume with new MuseScore .mp3 exports, you can tweak MuseScore's dynamics (using the inspector) to match the Sibelius dynamics by listening to a Sibelius .mp3, and then use the same hymn notated and exported in .mp3 via MuseScore.
OR...
If you still have Sibelius, you can record, for example, a test sample of scales using each scorewriter with the same dynamic markings. Then get the Sibelius scales into .mp3 (the way you used to do it), and export the MuseScore .mp3 file directly.
This way you can tweak (via the inspector) MuseScore's f to sound like Sibelius' f
MuseScore's mf, to sound like Sibelius' mf
MuseScore's p, to sound like Sibelius' p ... and so on.
Hopefully, you'll be able to match MuseScore's .mp3 volume simply by using these mapped (adjusted via inspector) dynamics, rather than normalizing through an audio app.

Regards.

In reply to by Jm6stringer

Until you said that, I hadn't spotted the Inspector allows the volume (velocity) to be adjusted! Seems like I learn something new about MS' capability every day :)

If, say, I decided "mp" needed to be equivalent to a velocity of 50 (rather than the default 64) to match Sibelius, is there some way it can be globally changed using the Inspector? I see that I can alter an *individual* occurrence of "mp", and if I copy and paste it to another part of the score the new velocity value *is* retained; but a new "mp" dragged from the palette has the default value of 64.

I guess I could just create the altered dynamics that I need in the first measure, and then remember to copy and paste them through the score as I need them, rather than use the palette.

In reply to by Marc Sabatella

Thanks Marc - that works beautifully!

Incidentally, I notice that the default mapping between dynamic mark and midi velocity changed between Beta 1 and the latest nightly builds.

Beta 1: ff=99, fff=99
Current: ff=112, fff=126

Not sure if that was deliberate or not.

In reply to by Steveeh

As mentioned, the defualts have not actually changed. What happened is that Beta 1 had a bug where the Inspector would not show threre-digit numbers for this field, so anything higher than 99 just displayed as 99. The values really were 112 and 126; they were just being displayed incorrectly. Obviously, that's fixed now.

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