[Tuxpaint-i18n] Fwd: [Tuxpaint-stamps] Reduced bitrate of many stamp description sounds

[Karl O. H. <ka...@hu...>]

[Forgot to CC the tuxpaint-i18n list.]

─────── Vidaresend melding ───────
Emne: 	Re: [Tuxpaint-stamps] [Tuxpaint-i18n] Reduced bitrate of many 
stamp description sounds
Dato: 	Sun, 2 Jun 2024 20:11:58 +0200
Frå: 	Karl Ove Hufthammer <ka...@hu...>
Til: 	tux...@li...



Bill Kendrick skreiv 02.06.2024 19:33:
>>> The other day I went through and converted all descriptive sound files
>>> in Tux Paint Stamps -- the sounds of people speaking the names of
>>> stamps -- from stereo to mono.  That saved almost 100MB of space
>>> used by those OGG files!
>> I think this is misguided. Ogg Vorbis uses channel coupling (similar to
>> joint stereo in the MP3 format), and since the recordings have been done by
>> (mono) microphones, converting from stereo to mono should in theory have
>> *no* effect.
> There were many recordings where the audio was only playing in one
> channel (e.g., if I had headphones on, I'd only hear the voice speaking
> the stamp description in my left ear, and silence on my right).

OK, I see. That would certainly be a reason to convert to mono. But when 
doing this, wouldn’t the software mix 50% sound with 50% silence, 
effectively halving the volume level? So you should normalize the volume 
afterwards.

Also note that there is *possibly* a difference in the audio output 
between a mono sound file and a stereo sound file with identical left 
and right channels. On a surround (5.1) system, PulseAudio/PipeWire by 
default (I think) plays mono sound through the centre speaker, but 
stereo sound through the left and the right front speakers. At least, 
this is what happens when you play the file through a simple audio 
player, e.g., mpv. But if libsdl does some mixing internally and only 
outputs stereo audio, this will not happen.

>      Original → Encode to Ogg → Reencode (mono) → Reencode (bitrate)
>
> Seehttps://wiki.hydrogenaud.io/index.php?title=Transcoding
>
> It would be much better to encode to the final format from the *original*
> uncompressed files (if you have them).
> Oof, yes, I would have to dig them back up from an earlier release
> I suppose.

They should all be in the Git history. Example:

git log --name-only 92d3d3236 | grep wav$

But I agree that digging them up, checking for any later updates 
(including renames) etc. would be a lot of work …

BTW, perhaps we could have a separate repository where we could store 
all the original (.wav or .flac) files, and *automatically* generate the 
.ogg (or .opus or whatever) files from these? Then it would be easier to 
do *future* updates, e.g., to reencode when a new and better format 
comes along, to downmix to mono, to normalize the sound level etc.

> So what do you think, should I open some tickets for these things?
> e.g.:
>
>   1. restore original sound files from pre-12/2024 and
>      do a smarter job at compressing them, doing all of this
>      at once (rather than lossily one step at a time):
>
>      a. stereo->mono the truly bad stereo (sound in one channel,
>         silence in the other) recordings
>
>      b. reduce the quality level
>
>   2. investigate use of the Opus codec
>
>      a. ensure it's usable on all major platforms
>         (I assume Windows, Linux, macOS, and Android are good;
>         Haiku would be the main question)
>
>      b. using the files as they existed after step 1a,
>         re-encode using Opus codec; assuming the file size
>         is better (smaller) over all, use it

There’s no rush *doing* all of this, but having open tickets could be 
nice, so that we don’t lose track.


-- 
Karl Ove Hufthammer