[low volume level music/sfx problem] how to boost volume 2x ?

[D0NM]

Hey everyone.

We use some .xm music files. Is there a neat way to boost up the music volume?
These tracks contain LOOPS. So it is impossible to replace with .MP3

AFAIK .ogg audio data files does support loops.

Has anybody solved such a problem with LOVE 0.10.2 ?

[TC1061]

I solved this problem with cloning Source object. And then this source is synchronizing with first:

Code: Select all

function love.load()
	local a=love.audio.newSource( --[[Something]] )
	local b=a:clone()
	a:play()
end
function love.update()
	if a:isStopped() and not b:isStopped() then
		b:stop()
	end
	if a:isPaused() and not b:isPaused() then
		if not b:isPlaying() then
			b:play()
		end
		b:pause()
	end
	if a:isPlaying() and not b:isPlaying() then
		b:play()
	end
	if a:isLooping() ~= b:isLooping() then
		b:setLooping(a:isLooping())
	end
	b:seek(a:tell())
end

[zorg]

You can open them with a tracker and raise the volume that way? If you're on windows, then OpenMPT is a good choice; check the global volume, see if samples are normalized or not, etc. (or if it's just quiet relative to other sounds in löve, then lower the volume of everything else with setVolume(less than 1.0).

That said, even if ogg files support loops, it may only be that the data contains a loop begin and loop end timestamp or something, not sure if löve handles that or not. On the other hand, you could always use tell and seek to implement looping on the supported bitstream formats (mp3, wav, ogg), which isn't that accurate, but it's something if you can't solve the volume issue.

[D0NM]

You can open them with a tracker and raise the volume that way? If you're on windows, then OpenMPT is a good choice; check the global volume, see if samples are normalized or not, etc. (or if it's just quiet relative to other sounds in löve, then lower the volume of everything else with setVolume(less than 0.1).

It is obvious. No. Not my case ((( Thank you.

That said, even if ogg files support loops, it may only be that the data contains a loop begin and loop end timestamp or something, not sure if löve handles that or not. On the other hand, you could always use tell and seek to implement looping on the supported bitstream formats (mp3, wav, ogg), which isn't that accurate, but it's something if you can't solve the volume issue.

Thank you. I use deprecated TEsound... so, looking for a nice substitution.

[D0NM]

I solved this problem with cloning Source object. And then this source is synchronizing with first:

The looping? Well just a manual music looping is not a problem. Thank you.

I mean a song that is composed in a way to have 2 parts :

[ intro part which is played only once in the beginning ] [ the looping part which is playing over and over ]

it is very cool to have some musical intro before the looped BMG.

[TC1061]

Its also very easy . But... It's better to just write a mini-library

Code: Select all

local volmulti={}
function volmulti.new(source,multiplier)
	local t={sources={}}
	t.source=source
	t.multiplier=multiplier
	if not (source and multiplier and type(multiplier)=="number") then error("invalid arguments for volmulti.new")
	for n=1,multiplier do
		local clone=source:clone()
		if n==1 then
			t.mainsource=clone
		else
		table.insert(sources,clone)end
	end
	return setmetatable(t,{
		__index=function(self,i)
			if i=="clone" then
				return function()
					return volmulti.new(self.source,self.multiplier)
				end
			elseif i=="call" then
				return function(self,func,...)
					if type(func) ~= "function" then
						error("invalid argument to call")
					end
					local mainreturns={func(self.mainsource,...)}
					for n,s in pairs(sources) do
						func(s,...)
					end
					return unpack(mainreturns)
			end
			return function(self,...)
				local mainreturns={self.mainsource[ i ](self.mainsource,...)}
				for n,s in pairs(self.sources) do
					s[i](s,...)
				end
				return unpack(mainreturns)
			end
		end})
end
return volmulti

Then you can use values returned from volmulti.new as normal sources (Except for external LOVE2D functions (e. g. love.audio.stop), for these you must call multisource:call(love.audio.stop))

[zorg]

Its also very easy . But... It's better to just write a mini-library
<code>

Be aware that this has many shortcomings, including:
- The inability to multiply your volume levels by non-integer values (more-or-less easily fixable),
- Reaching the simultaneously active source count limit way faster than intended (not really fixable),
- Generally less ideal than if you just lower everything else's volume; there's a reason why audio editors and other places denote sound levels as 0dB maximum and -infinity dB minimum;

0.11 will give the ability to software-mix audio on the lua side too, so it'll be a boon for many, but duping sources like this is never the right solution. :c

[TC1061]

I don't know what is "0.11". It's really to fix all of these issues. First can be fixed easily. Just divide the volume what you want by "multiplier" and call with this value the multisource:setVolume. Second isn't a problem, it can be fixed by limiting the "multiplier" in volmulti.new. Third is offtopic. The topicstarted wanted to boost volume 2x. And really, duplicating sources isn't good, but if they will be synchronized it's ideal solution.

[zorg]

I don't know what is "0.11".

The current Löve version released is 0.10.2, the next one will be 0.11.0, that's what i'm talking about; it'll have additional audio features, like queueable sources, which you can use to push arbitrary (audio) data on to yourself, continuously. (Along with other additions)

It's really to fix all of these issues.

I did say the first was easy to fix... the others less so though.

First can be fixed easily. Just divide the volume what you want by "multiplier" and call with this value the multisource:setVolume.

But then that won't be a "multiplier", that'd be a "divisor"... also it's still incorrect. My fix (using your original idea/code) would have been just to duplicate the source one plus as many times as big as the multiplier was ((multiplier%1+1) times, or math.ceil(multiplier) times, either one is fine), then adjust the last one's volume to the remainder, or the fractional part, and it's fixed.

Second isn't a problem, it can be fixed by limiting the "multiplier" in volmulti.new.

Yeah, but you can't deny that if you're doing this to many sounds, the limit can still be reached way faster than if you didn't do this.

Third is offtopic. The topicstarted wanted to boost volume 2x. And really, duplicating sources isn't good, but if they will be synchronized it's ideal solution.

It's not off-topic, it's literally how everything else solves this; everyone prefers normalized numbers, so either [0.0,1.0] or [-1.0,1.0]; you can't logically increase 1.0 unless you make everything else quieter, and then define your bigger number as 1.0 instead.

Also, i'm talking about one specific program's audio output, let's forget the operating system, the soundcard and the speakers/headphones for a second. The sources may still desync during playback since you're not in control of sample-accurate playback (yet), and as i said, boosting volume in a closed-system, which here, is the program itself, means that you're just adjusting source volumes so that if all sources are at 1.0, you need to lower the ones you don't want to be louder... with 0.11's QSources, you can divide everything simultaneously when doing the final mix, so you can have the sources be premultiplied by a value bigger than 1.0... but this of course isn't simple to code.

Let me make a very simple example, if there's only one source in your game, which makes sound, and it's already at 1.0 volume, you can't do anything -in- the program itself, you'll need to go outside it, and either raise the volume in the volume control panel (if it's not at max, or 1.0 already), or go to the physical side of things, and either raise the volume on your speakers/headphones (if they have an amplifier in them), or you can't do anything else.

[grump]

duplicating sources isn't good, but if they will be synchronized it's ideal solution.

No. It's the worst possible and most inefficient "solution" there is. It's not even a real solution, it's a crazy hack at best and nobody should use it.

The ideal solution is to maximize the volume/loudness of the source data in a preprocessing step, so you don't have to care about it at runtime. If the source already uses the maximum dynamic range, just lower the volume of everything else.