Puppy Linux Discussion Forum

I find my deadbeef does not seem to work for mp3 folders to smooth out the volume in different albums. Is there a way to do this for mp3 files perhaps using a terminal comand with ffmpeg?

Copy and paste this script into a new file somewhere in your executable path (/usr/local/bin) and give it a name and make it executable.
Copy some of your .mp3s to a different folder to be safe and try the script below inside the that folder:
Create the "newdir" as a sub directory for the normalized files.

<USE AT YOUR OWN RISK>

#!/bin/sh
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" newdir/"$song"
done

Trapster wrote: Sat Mar 18, 2023 12:09 am

Copy and paste this script into a new file somewhere in your executable path (/usr/local/bin) and give it a name and make it executable.
Copy some of your .mp3s to a different folder to be safe and try the script below inside the that folder:
Create the "newdir" as a sub directory for the normalized files.

<USE AT YOUR OWN RISK>

Code: Select all

#!/bin/sh
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" newdir/"$song"
done

It works!! , I noticed bit rate reverts to about 128Hz, even if the original mp3 is recorded at 256Hz, is there a parameter that is missing that will replicate to the original bit rate?

gychang wrote:

noticed bit rate reverts to about 128Hz, even if the original mp3 is recorded at 256Hz, is there a parameter that is missing that will replicate to the original bit rate?

Yes, because 128k is the default if the bitrate is not specified, add e.g. "-b:a 256k" or better "-b:a 320k" (re-encoding lossy audio means quality loss, I would choose highest 320k to get closest to the original), so then;

mkdir -p newdir
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" -b:a 320k newdir/"$song"
done

fredx181 wrote: Sat Mar 18, 2023 9:31 am

gychang wrote:

noticed bit rate reverts to about 128Hz, even if the original mp3 is recorded at 256Hz, is there a parameter that is missing that will replicate to the original bit rate?

Yes, because 128k is the default if the bitrate is not specified, add e.g. "-b:a 256k" or better "-b:a 320k" (re-encoding lossy audio means quality loss, I would choose highest 320k to get closest to the original), so then;

Code: Select all

mkdir -p newdir
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" -b:a 320k newdir/"$song"
done

thanks!!

gychang wrote: Sat Mar 18, 2023 1:06 pm

fredx181 wrote: Sat Mar 18, 2023 9:31 am

gychang wrote:

noticed bit rate reverts to about 128Hz, even if the original mp3 is recorded at 256Hz, is there a parameter that is missing that will replicate to the original bit rate?

Code: Select all

mkdir -p newdir
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" -b:a 320k newdir/"$song"
done

thanks!!

my final version for those interested.

#!/bin/sh

p=/root/Downloads/post

mkdir -p $p
for song in *.mp3
do volume=$(ffmpeg -i "$song" -af "volumedetect" -vn -sn -dn -f null /dev/null 2>&1 | awk '/max_volume/{gsub("-","");print $5}')
ffmpeg -i "$song" -af "volume=${volume}dB" -b:a 320k $p/"$song"
done

#mv files to original folder
mv $p/* ./ 
#remove the folder no longer needed
rmdir $p

#exit the terminal
killall urxvt

Be careful with "killall", if another instance of urxvt is running it will exit too
And does mv $p/* ./ replace the original files ?

fredx181 wrote: Sat Mar 18, 2023 7:32 pm

Be careful with "killall", if another instance of urxvt is running it will exit too
And does mv $p/* ./ replace the original files ?

I was unable to figure out how to kill the terminal that is running the script.
mv $p/* ./ replaces the original files indeed

I am not too versed on the bash scripts so this is what I came up with...

Try "EXEC exit"

Clarity wrote: Sat Mar 18, 2023 8:33 pm

Try "EXEC exit"

tried "EXEC exit", "exec exit" and "exec exit 0" do not work for me...

exit

Below all from quick Google - there are probably plenty other ways.

Assuming you are running script from inside a terminal and want the terminal to close automatically at the end. The exit at end of the shell script doesn't itself close the terminal. But running the script as follows would:

<path_to_script> && exit

For successful command completion.
or simply:

<path_to_script>; exit

Which will always exit even if script returned as failed.

Since I don't really know what you want, might be worth mentioning you can also kill the Parent Process ID:

kill -9 $PPID

If that kill put as last line of your script, it would kill the terminal and all child processes associated with it. Don't know that that is a great idea though since could have horrible consequencies if you started the script some other way and for example somehow initial process (init) had become the parent... Never that I can think of actually used that kill -9 $PPID method myself.

It may be that you want to run your script via a desktop file so it appears in main Desktop Menu. In that scenario you can include in the .desktop file the line: Terminal=true
and you will see the command running (but terminal should close automatically at end) or Terminal=false, and command should work okay but no Terminal will pop up. Your script would of course have to include all the directory/file information you want it to start with of course (paths involved and so on).

I am not sure it this is what you are after, but if your utility is executed in the terminal as
exec your-scriptname would it give a result you seek?

I am not a coder, so this is just an idea I had.

There are many others ENORMOUSLY greater in Linux scripting than I will ever be.

an used way to get the pid of a called command/script is
to put the content of var $! immediately after the call anywhere.

let's say for example we call a second urxvt:
urxvt

When it starts, the var $! gots filled with the pid.
To set that content anywhere, we have to say
the commandcalling part 'don't wait until the called command ends'
= we add a & at the end of the call
urxvt &

And after that & we set the PID in 'our' var CallPID
with echo the Var $! and put the echoed value in our Var:
urxvt & CallPID=$(echo $!)

after that we can show the content with echo $CallPID.
As a oneliner to execute in a consolewindow:
urxvt & CallPID=$(echo $!); echo "CallPID=$CallPID"

if you need the PID also in a called script,
you have to export CallPID, so the var get set in the environment
of called scripts.
urxvt & CallPID=$(echo $!); echo "CallPID=$CallPID"; export CallPID

hope it helps, Eastler

oh, damned, my brain

There is a much easier way: The Var $$

for example go in a shell, do:
echo "$$"
it shows the pid

to get it in a var you can do:
myVar=$(echo "$$")

if you need that in called commands/scripts
you have to export the var
myVar=$(echo "$$"); export myVar

hope it helps, Eastler

I presume something was wrong with what Mochimoppel suggested and then deleted?

export myVar=$$

There is definitely nothing wrong with not "reading aloud" the content of one variable to another. However, export myVar=$$ will be hardly different from using $PPID in a child script.

wiak wrote: Wed Mar 22, 2023 11:01 pm

I presume something was wrong with what Mochimoppel suggested and then deleted?

Code: Select all

export myVar=$$

Maybe Mochimoppel felt that his unsolicited advice was too trivial and not welcome?

MochiMoppel wrote: Thu Mar 23, 2023 12:52 am

wiak wrote: Wed Mar 22, 2023 11:01 pm

I presume something was wrong with what Mochimoppel suggested and then deleted?

Code: Select all

export myVar=$$

Maybe Mochimoppel felt that his unsolicited advice was too trivial and not welcome?

Maybe, I wouldn't know, but now expect the alternative he/she suggested is okay.
I believe it is always good to know better alternatives since we all learn coding techniques from each other on a forum. Improved forms are not trivial really nor should they be unwelcomed somehow or be considered negative criticism.

How was the post deleted? Doesn't help continuity when info disappears.

In my experience different posts resonate with different levels of experience and different user needs. It is best when posts remain in place to assist understanding of the thought and education processes.

Burunduk wrote: Wed Mar 22, 2023 11:49 pm

However, export myVar=$$ will be hardly different from using $PPID in a child script.

It is not the same though - sometimes we want the original parent PID when child of child of child situation.

mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ export myVar=$$
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ bash
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $myVar
2429
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $PPID
2429
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ bash
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $myVar
2429
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $PPID
2435
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ bash
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $myVar
2429
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ echo $PPID
2443

PPID isn't per se an environment variable, it's from the shell, so if you try exporting it, a new shell will overwrite it with new PPID value. Hence, export anyvar=$$, is a useful construct sometimes.