Przygotowanie pliku do publikacji

O narzędziach do przygotowywania plików do publikacji zakończyłem pisać w maju, jednak dzisiaj chciałbym pokazać w skrócie, jak można uprościć sobie życie, zwłaszcza jeśli chcemy publikować wiele nagrań w krótkim czasie (bo na przykład robimy dużo testów, ha, ha!)

Żebyśmy jednak mieli jasność, na początek wyjaśnienie, co jest w ogóle celem. Otóż w moim wypadku jest to przygotowanie nagrania na kanał testowy lub kanał główny. Czyli chcę mieć przygotowany zarówno film w formacie mp4 z odpowiednią wizualizacją, jak i opis do wklejenia przy umieszczaniu filmu na YouTube. Ponadto, już po samej publikacji chcę szybko udostępnić aktualną listę nagrań na mojej stronie domowej (jest też wersja dla kanału głównego) - nie chodzi już nawet o szybsze wyszukiwanie, ale też o linki do osadzania na blogu, bo ułatwia mi to późniejsze pisanie artykułów.

Zarówno "okładki", jak i opisy nagrań muszą zawierać jak najwięcej szczegółów i informacji, czym dany utwór został nagrany, jakie efekty zastosowałem, musi być tam precyzyjna informacja o samej kompozycji i kompozytorze. I dobrze, by większość rzeczy dała się zautomatyzować.

Wysiłek, żeby się nie narobić

Z perspektywy czasu mogę ocenić, że dzisiejsze minuty, zamiast dawnych godzin, potrzebne na przygotowanie finalnego nagrania są konsekwencją włożenia całkiem sporej pracy w rozgryzienie całego procesu. Nie wszystko od początku szło tak gładko, wiele rzeczy robiłem niepotrzebnie wielokrotnie lub wymagały one dodatkowych zabiegów, które dzisiaj już nie są potrzebne.

Grunt w DAW

Zasadniczo nauczyłem się bazować na danych (metadanych), które wpisuję jeszcze w programie DAW, czyli w moim wypadku w Fender Studio Pro. Po pierwszym wczytaniu pliku MIDI zapisuję go pod odpowiednią nazwą w odpowiednim katalogu (każdy kompozytor ma własny) i od razu przechodzę do edycji metadanych:

Raz wpisane metadane będą mi służyć aż do przygotowania opisu na YouTube

Jak widać, założyłem sobie tutaj dwie rzeczy: metadana "Album" zawiera pełną nazwę biblioteki, z której korzystam, zaś "Composer" zawiera kod rodzaju utworu (mam ich całkiem sporo: keys, orchestra, harp, organ itd.), co pomaga mi później w automatycznym generowaniu okładki. Dlaczego wykorzystałem akurat te dwa pola? "Album" wydaje mi się w miarę naturalny, poza tym jest wyświetlany przez odtwarzacze, więc widać go nawet, jeśli nie widać okładki. "Composer" jest kompromisem - początkowo używałem "Comments", ale niestety, okazało się, że akurat komentarze są używane w różny sposób przez różne programy, a inne pola czasem nie są używane w ogóle.

Dodatkowo w oknie renderowania często zdarza mi się dodawać do nazwy pliku kodową nazwę biblioteki, jeśli testuję różne instrumenty i renderuję je wszystkie z jednego projektu:

Nawet nazwa pliku może mieć znaczenie, jeśli się to przemyśli

Jeśli mam zatem 8 ścieżek z tymi samymi nutami MIDI, ale przypisanych do różnych instrumentów, włączam jedną ścieżkę w tryb Solo i renderuję, dodając do nazwy np. vsl_280 czy r275, zgodnie z przygotowanym mapowaniem:

Na potrzeby AudioViewera przygotowałem listy kompozytorów i listy bibliotek, więc żal było tego nie wykorzystać

Python!

Kiedy mam już wyrenderowany plik audio, czas zająć się przygotowaniem okładki, która stanie się treścią filmiku do publikacji. Tutaj mam pewne rozgraniczenie: utwory testowe mają okładki generowane kompletnie automatycznie, natomiast dla utworów na główny kanał okładki ciągle przygotowuję ręcznie w Affinity Designerze:

Affinity Designer 2 i ręczne budowanie okładki na główny kanał

Jeśli zaś chodzi o okładki automatyczne, od dłuższego czasu porzuciłem ręczne wywoływanie pythonowych skryptów na rzecz dopracowanego (już) AudioViewera:

Udało mi się przekształcić AudioViewera w naprawdę potężne narzędzie, choć... nie wygląda na to

Podstawowa rzecz to to, że ma on już wbudowane listy kompozytorów oraz wszystkich moich bibliotek, więc nie muszę niczego wpisywać ręcznie. Po drugie, umożliwia on - przyciskiem Cover - automatyczne wygenerowanie okładki na podstawie metadanych i pewnych, ehm..., heurystyk.

Najpierw ustalane jest tło okładki - a dzieje się to na podstawie wpisanego wcześniej kodu z pola "Composer":

Tła okładek na każdą okazję

Potem nakładana jest na okładkę "naklejka producenta", czyli specjalny kolorowy pasek w narożniku, który trochę ułatwia odszukiwanie nagrań na podstawie miniatur okładek:

Narożne "naklejki" różnych producentów

Kiedy już tło i naklejka są gotowe, następuje wypisanie w odpowiednich miejscach metadanych z pliku, dzięki czemu otrzymuję gotową okładkę.

O ile przycisk Cover umożliwia zbudowanie okładki i jej wzrokową ocenę (czasem trzeba dodać "niełamliwe spacje", by wyrazy dobrze się zawijały), to kluczowy jest przycisk Build. Mam kilka jego wariantów, co widać na zrzucie powyżej, jego zadaniem jest zrobienie całej "brudnej roboty".

Normalizacja na RTX

Po pierwsze, robiona jest normalizacja do -15LUFS, co przyjąłem sobie jako standard na moich kanałach. Kiedyś stosowałem normalizację zapewnianą przez ffmpeg (koder wideo), ale szybko okazało się, że jest ona dynamiczna i ciche fragmenty były mocno pogłaśniane, zaś te głośne - mocno "prasowane", przez co całe nagranie brzmiało może i dobrze do puszczenia w radiu, ale kompletnie traciło dynamikę.

Później nauczyłem się, jak można w Pythonie wykorzystać wtyczki VST3 i korzystałem z takiej właśnie możliwości, jednak denerwowała mnie powolność obróbki. W końcu napisałem swój własny algorytm normalizujący, który działa wieloprzebiegowo i zamiast prostej limitacji (obcięcia) głośnych fragmentów, po prostu je nieco ścisza, cały czas kontrolując ogólną głośność. W dodatku udało mi się do wykonania normalizacji zaprząc RTX3060 przy wykorzystaniu biblioteki CuPy, więc teraz całościowa normalizacja LUFS nawet długich nagrań trwa dosłownie kilkanaście sekund, z czego 1/3 czasu to przygotowanie rdzeni CUDA do pracy.

ffmpeg

Build, po znormalizowaniu pliku, tworzy mi jeszcze wersję mp3 do słuchania (z transferem wszelkich metadanych i osadzeniem okładki), po czym na sam koniec przygotowywany jest plik wideo dla YouTube'a. Tu wykorzystuję ffmpeg, który - odpowiednio skonfigurowany - potrafi nie tylko wygenerować wideo na bazie pliku audio i pliku graficznego okładki, ale także jakiś czas temu opanowałem, jak zrobić fade-in i fade-out, przez co filmiki wyglądają mniej surowo. Eksperymentowałem także z wyświetlaniem waveformy:

"Animowana" waveforma - nie jestem przekonany...

Sam nie wiem, nie do końca jestem przekonany do tego rozwiązania...

W ten sposób mam gotowy i plik mp3, i plik mp4, a sam AudioViewer ma jeszcze bardzo przydatną funkcję Copy, która wszystkie metadane i dodatkowe informacje wkleja w postaci gotowego ciągu znaków do systemowego schowka, więc przy wrzucaniu filmu do YouTube'a, mogę całość wkleić w pole opisu, a potem poprzeklejać szybko do tytułu i słów kluczowych.

I tu kończy się rola AudioViewera i przycisku Build, a plik wideo jest załadowany na właściwy kanał.

Script Commander

Na sam koniec odpalam jeszcze Script Commandera i uruchamiam skrypt, który łączy się z YouTube, pobiera aktualne dane o filmach (dla wszystkich moich kanałów), po czym zasila danymi moją stronę domową:

Script Commander przydaje się do wielu różnych zadań, do pobierania danych z YouTube'a także

Koniec końców zawsze powinny być tam aktualne dane, odpowiadające temu, co jest na kanałach.

Ostatecznie

W praktyce zatem powyższe rozwiązania bardzo się sprawdzają. Szczególnie mocno ułatwiły mi życie przy testowaniu fortepianów, bo to tutaj potrzebne było w miarę proste tworzenie nagrań tych samych utworów, ale granych innymi bibliotekami. Robiłem to już, oczywiście, wcześniej także dla orkiestr, ale przy wielościeżkowych plikach z dziesiątkami artykulacji porównawcze nagrania tworzy się dużo trudniej, więc i było ich mniej.

Jak to zwykle zatem bywa, dopiero przy końcu zabawy w danej dziedzinie dorabiam się wydajnych narzędzi, dokładnie to samo było z podcastowaniem, gdzie techniczne przygotowanie ostatnich odcinków trwało niepomiernie krócej niż męki z tymi pierwszymi. Obecnie jest dokładnie to samo - pierwsze mock-upy powstawały w dużych trudach i dopiero teraz oszczędzam sobie mnóstwa niepotrzebnej, ręcznej roboty. No cóż, trzeba mieć nadzieję, że jednak w przyszłości taki AudioViewer się jeszcze przyda - bo ze Script Commandera korzystam bardzo często, a powstał także na potrzeby muzyczne.

Podsumowując - namawiam do nauki programowania i korzystania z możliwości ekstremalnego dopasowania programów do własnych potrzeb!