Oprogramowanie na usługach podcastera

W jakim celu powstały komputery? Ano w takim, by wspomóc człowieka w mozolnych czynnościach - początkowo były to głównie obliczenia, ale obecnie spektrum możliwości jest dużo szersze i możemy wspomagać się różnymi aplikacjami, aby ułatwić sobie życie. Warto, by podcaster czy osoba zajmująca się dźwiękiem znała takie programy, jak sox, ffmpeg czy lame. O wykorzystaniu sox pisałem przy okazji zmagań z dzieleniem plików z RødeCastera, o ffmpeg - w artykule o konwersji plików mp3 w filmy, zaś o lame chyba jeszcze nie pisałem, ale jest to chyba najpopularniejszy program do tworzenia plików mp3 właśnie.

Te trzy programiki łączy jedno - działają one w tzw. linii poleceń, czyli nie mają pięknych, gładkich i błyszczących interfejsów użytkownika (aczkolwiek w sieci można znaleźć sporo nakładek, wystarczy w wyszukiwarkę wpisać nazwę programu i "gui"). Dlaczego i jak ktoś miałby używać tak "nieprzyjaznych" programów? I w jaki sposób może to przyspieszyć cokolwiek?

Czarne okienka

Ten wpis nie ma być kursem obsługi linii poleceń - tego typu tekstów można znaleźć w sieci sporo, na przykład ten. Nie będzie to także instruktaż korzystania z wymienionych programów dźwiękowych. Chciałbym po prostu zwrócić Waszą uwagę na bardzo użyteczne możliwości, które z reguły są darmowe i wymagają jedynie (jedynie?) poświęcenia chwili - dłuższej lub krótszej - na naukę. Przy czym zwykle nie trzeba niczego wymyślać samodzielnie, bo - jak to się mawia - w internecie jest już wszystko.

Tak wygląda pusta linia poleceń, znajdujemy się w głównym katalogu dysku C:

Przykład wywołania programu sox z parametrami, dzięki którym dowiemy się, ile kanałów zawiera dany plik (tutaj wyświetlony wynik to 1, czyli plik jest monofoniczny)

Chciałbym zatem przedstawić pewien praktyczny problem, z którym najpierw walczyłem ręcznie, by go sobie wreszcie zautomatyzować. Nie będę udostępniał gotowych skryptów, bo są one dopasowane do mojego sposobu pracy - chyba, że pojawi się zapotrzebowanie.

Problem praktyczny

Od czasu do czasu nagrywam sobie "dzienniki audio" - krótkie materiały, w których opisuję pomysły na podcast czy krótkie testy urządzeń, zanim nagram "Narzędziownik podcastera". Do nagrywania używam czegokolwiek, co mam akurat pod ręką - rejestratora, telefonu czy (najczęściej) RødeCastera, bo tu zawsze jest podłączony jakiś mikrofon.

Żeby się nie zagubić w kilkudziesięciu (na tę chwilę) plikach, postanowiłem je sobie zgrywać do konkretnego katalogu w komputerze. Samo zgrywanie ujawniło, że trzeba też coś wymyślić w kwestii nazw plików, bo każde urządzenie ma własną strategię w nazewnictwie. Po namyśle stwierdziłem, że format "RRRR-MM-DD" z datą utworzenia będzie wystarczający, a jeśli zdarzą się dwa nagrania z tego samego dnia, to po prostu dodam sufiksy w rodzaju "_1", "_2" itd.

A, no i dodatkowo fajnie byłoby, gdyby pliki były małe - czyli trzeba je zmonofonizować i skonwertować do formatu mp3, bo akurat w tych "dziennikowych" nagraniach ekstremalna jakość nie jest najważniejsza. Do późniejszego odsłuchu warto byłoby też poddać te nagrania normalizacji do jakiejś wspólnej głośności, żeby nie machać gałką głośności przy przesłuchiwaniu.

Jak widać, nie są to jakieś skomplikowane procesy: biorę plik, zmieniam mu nazwę na odpowiednią, wczytuję do WaveLaba, monofonizuję, normalizuję do -19LUFS, zapisuję jako mp3. No i kopiuję do odpowiedniego katalogu na dysku, ewentualnie jeszcze dopasowując nazwę, jeśli trafi się duplikat. Tyle że do przerobienia miałem ponad 11 godzin nagrań, a i normalnie zgrywam je zwykle partiami, a nie pojedynczo. Czyż nie byłoby łatwiej tylko zgrać pliki, zaznaczyć je i wydać magiczne polecenie: zmień je w pliki "dzienników audio"?

Siła linii poleceń

Siła linii poleceń tkwi w tym, że możemy sami ustalić, co się ma dziać i co chcemy robić - a potem to powtarzać. Oczywiście nie chodzi o to, by za każdym razem wpisywać skomplikowane polecenia - można je sobie zachować w postaci plików bat lub napisać skrypt w jakimś prostym języku programowania, np. Pythonie. Przećwiczyłem oba podejścia i zdecydowanie preferuję Pythona, jednak i on koniec końców wywołuje komendy w linii poleceń.

Przede wszystkim trzeba zdecydować, co chcemy zrobić i jakie programy mogą nam w tym pomóc. Potem wystarczy przeczytać dokumentację, żeby dowiedzieć się, w jaki sposób dany program należy uruchomić (z jakimi parametrami) i to wszystko.

W moim przypadku pierwszą czynnością (poza zmianą nazwy pliku) jest monofonizacja pliku. Doskonale do tego celu nadaje się wspomniany wyżej sox, bo ma on aż dwie możliwości: albo wyciągniemy z pliku pojedynczy kanał, albo zmiksujemy nagranie stereo do pliku mono. Sięgamy zatem do dokumentacji i dość szybko znajdujemy dwa rozwiązania. Wyciągnięcie pojedynczego (w tym wypadku lewego) kanału:

sox.exe plik_zrodlowy.wav plik_mono.wav remix 1

Możemy też zmiksować oba kanały stereo i w ten sposób również otrzymać nagranie mono:

sox.exe plik_zrodlowy.wav plik_mono.wav channels 1

Drugim krokiem była zakładana normalizacja do -19LUFS - i tu już ze znalezieniem odpowiedniego programu nie było tak łatwo. Sox wprawdzie oferuje opcję normalizacji za pomocą polecenia:

sox.exe --norm plik_zrodlowy.wav plik_znormalizowany.wav

Jednak jest to normalizacja oparta na szczytach, czyli peakach - są one "dociągane" do 0dBFS i tyle. Można wprawdzie użyć limitera, kompresora albo opcji "guard", ale w każdym przypadku wymaga to na ogół uprzedniego zbadania pliku, o jaką wartość chcemy (musimy) go pogłośnić.

Za to, jak się okazuje, ffmpeg ma odpowiednią opcję podniesienia głośności do określonego poziomu z możliwością jednoczesnego użycia limitera w celu eliminacji przesterowań. Służy do tego filtr loudnorm, który wystarczy odpowiednio skonfigurować:

loudnorm=I=-19:LRA=11:TP=-1.0

Jak widać, podajemy mu oczekiwaną głośność w LUFSach (głośność zintegrowana), do tego rozpiętość dynamiczną w decybelach (LRA) i próg dla true-peak - tutaj standardowo -1dB. Cała linia polecenia w moim przypadku wyglądała następująco:

ffmpeg.exe -i plik_zrodlowy.wav -acodec pcm_s24le -ar 48000 -filter:a loudnorm=I=-19:LRA=11:TP=-1.0:dual_mono=false:offset=1:print_format=summary plik_znormalizowany.wav

Dokumentacja ffmpeg jest potężna, więc jeśli komuś potrzeba jakichś specjalistycznych funkcji, warto ją przejrzeć. To naprawdę zadziwiające, jak wiele potrafi ten program. Wersję skompilowaną dla Windows można znaleźć na stronie https://www.gyan.dev, w większości wypadków wystarczy pobrać archiwum zip wersji Essential.

Tak znormalizowany plik chciałbym jeszcze skonwertować na format mp3, a jednym z lepszych programów potrafiących to wykonać jest lame (wersję skompilowaną można pobrać stąd, bo na stronie projektu jest dostęp tylko do wersji źródłowej). Można przyjrzeć się dokumentacji, ale zasadniczo, żeby skonwertować plik wav do mp3 z bardzo dobrą jakością, można użyć następującej składni:

lame.exe -q0 -b320 plik_zrodlowy.wav plik.mp3

Program lame w akcji - właśnie przeprowadził konwersję na format mp3

Teraz, mając już wiedzę, jak wykonać poszczególne kroki, możemy zapisać zawartość pliku bat, który jest zwykłym plikiem tekstowym z rozszerzeniem bat, zawierającym powyższe instrukcje. Co ciekawe, uruchamiając taki plik z linii poleceń, możemy przekazać do niego nazwę pliku do przetworzenia, a w samym skrypcie możemy tę nazwę wykorzystać, bo jest ona dostępna pod nazwą %1 (ewentualnie %2, %3, %4 - każdy kolejny parametr dostaje swoją liczbę). Załóżmy więc, że napiszemy na szybko skrypt, który będzie konwertował podany plik do pliku mp3. Plik to_mp3.bat będzie miał następującą treść:

lame.exe -q0 -b320 %1 plik.mp3

A sposób wywołania:

to_mp3.bat nazwa_pliku.wav

To się przydaje!

Powyższy pliczek bat jest tylko małym przykładem. W tym pliku można zawrzeć wszystkie wywołania, które opisałem wcześniej, więc wywołując pojedynczy plik bat i przekazując do niego jedną nazwę pliku, spowodujemy, że wykona się więcej instrukcji, po kolei przekształcając plik źródłowy w plik docelowy, już bez naszego udziału. Im więcej rzeczy trzeba zrobić, tym bardziej opłaca się poświęcić czas na przygotowanie podobnego pliku.

Warto też na pewno przyjrzeć się Pythonowi, który jest prostym (choć potężnym) językiem skryptowym, w którym można łatwo uzyskać wiele rzeczy trudnych do uzyskania w pliku bat (łącznie z pobieraniem czy wysyłaniem plików do sieci). Ja ostatecznie używam właśnie skryptu w Pythonie (choć większość "dzienników" przetworzyłem plikami bat) - bo szybko okazało się, że niektórych funkcjonalności, np. wyciągania pojedynczych kanałów dźwięku, mogę używać przy innych okazjach. A współdzielić kod w Pythonie jest łatwiej niż łączyć ze sobą wiele plików bat.

Tak czy owak, w obecnej chwili zgrywam pliki "dzienników" gdziekolwiek, uruchamiam skrypt i po chwili potrzebnej na normalizację i kompresję, wszystko nazwane w odpowiedni sposób ląduje w określonym miejscu na dysku, samo synchronizuje się z chmurą i... tyle. Skrypt przy okazji dba o unikalność nazw plików czy też sam rozpoznaje, ile kanałów ma dany plik (żeby niepotrzebnie nie przeprowadzać konwersji na mono).

I właśnie od tego są komputery.