Czy twój komputer poradzi sobie z napisami i głosem lektora?

Masz roboczy montaż demonstracji produktu, nagranie rozmowy dwojga współpracowników i trzy linijki narracji do poprawy. Wysłanie nagrania do usługi transkrypcji, a skryptu do usługi syntezy mowy to dobrze znany sposób pracy. Wykonywanie obu zadań na komputerze do montażu może ułatwić kolejne poprawki, zwłaszcza gdy materiał źródłowy musi zostać na tym urządzeniu. Za kolejkę, pliki modeli i kontrolę jakości odpowiada wtedy montażysta.

4 listopada 2026 roku otwarty projekt inferencyjny llama.cpp wydał wersję 0.9.0. Dodaje ona transkrypcję offline za pomocą NVIDIA Nemotron 3.5 Transcribe, syntezę mowy za pomocą Chatterbox oraz gotowe głosy Pocket TTS, których można używać bez nagrania referencyjnego. Informacje o wydaniu opisują transkrypcję w 40 językach, możliwość podania kontekstu w poleceniu i oznaczanie rozmówców. Każda zmiana może się przydać w tym samym procesie montażowym, ale każda stawia inne wymagania komputerowi i osobie sprawdzającej wynik. Informacje o wydaniu llama.cpp v0.9.0

Jeśli znasz llama.cpp z prób uruchamiania lokalnego chatbota, łatwo przeoczyć zakres tego wydania. To środowisko uruchomieniowe do inferencji obsługiwanych architektur, z narzędziami do wczytywania zgodnych plików modeli i przyjmowania żądań. Aktualizacja poszerza zestaw zadań dostępnych w tym samym środowisku. Aplikacja korzystająca z niego nadal decyduje o miejscu zapisu dźwięku, prezentacji poprawek i tym, kiedy plik jest gotowy do publikacji. Projekt llama.cpp

Telli.sh uruchomił oficjalną kompilację dla Windows powiązaną z wydaniem i odtworzył na ilustracji rzeczywisty wynik polecenia sprawdzającego wersję. Wynik potwierdza tożsamość kompilacji. Kompilacja b12110 powiązana z wydaniem

Napisy zaczynają się od transkrypcji, którą można poprawić

Załóżmy, że ktoś z zespołu nagrywa dziesięciominutowy pokaz produktu przed premierą. Inna osoba wchodzi mu w słowo, by poprawić nazwę funkcji. Potrzebujesz przeszukiwalnej transkrypcji, wstępnego podziału wypowiedzi według osób i wreszcie napisów pojawiających się w odpowiednich klatkach. To trzy różne wyniki. Pierwszy jest tekstem, drugi oznaczeniem redakcyjnym, trzeci wymaga synchronizacji z obrazem.

Integracja Nemotron pomaga zacząć od pierwszych dwóch. Scalona implementacja obsługuje transkrypcję offline z opcjonalnym kontekstem i oznaczaniem rozmówców. Może zachować informacje o osobach między kolejnymi oknami przetwarzania w jednym nagraniu. Według opisu zmiany znaczniki czasu dla pojedynczych słów i tryb strumieniowy były poza zakresem integracji. W praktyce można przepisać ukończone nagranie, poprawić tekst, a gdy wymaga tego materiał końcowy, dopasować czasy w osobnym etapie montażu lub opracowywania napisów. Integracja Nemotron 3.5 Transcribe

Ilustracja Telli.sh. Lokalną transkrypcję można poprawić. Dopasowanie czasów napisów następuje po sprawdzeniu tekstu i oznaczeń rozmówców.

Kontekst w poleceniu jest szczególnie interesujący dla zespołów używających słów rzadko spotykanych w zwykłej rozmowie. Przy nagraniu o fikcyjnej funkcji Pine Relay podaj krótką listę oczekiwanych nazw i skrótów, a potem przepuść ten sam klip bez listy. Sprawdź, czy kontekst poprawił nazwę, czy wstawił ją tam, gdzie nikt jej nie wypowiedział i czy zmienił liczby albo inne słowa. Ogranicz listę, aby dało się wyjaśnić wpływ konkretnego wpisu na wynik. Asystent transkrypcji powinien ułatwiać sprawdzenie nietypowych terminów bez zmieniania treści nagrania pod wpływem słownika.

Rozpoznawanie rozmówców wymaga osobnej kontroli. W czystym nagraniu wywiadu dwie osoby mogą być łatwe do odróżnienia. Trzeci rozmówca słyszany z telefonu i kilka nakładających się zdań mogą zmienić ilość potrzebnych poprawek. Odsłuchaj zmiany rozmówców oraz najdłuższe wypowiedzi każdej osoby. Transkrypcja może zawierać wszystkie właściwe słowa, a mimo to przypisać ważną decyzję niewłaściwej osobie. Zachowuj rozróżnienie między oznaczeniami modelu a imionami przypisanymi ręcznie, dopóki nagrania nie sprawdzi ktoś, kto je zna.

Wyeksportowane napisy przeczytaj podczas oglądania nagrania. Zdanie, które dobrze wygląda w dokumencie, może wyjść poza ekran, pojawić się przed ważnym momentem lub pozostać widoczne po rozpoczęciu wypowiedzi następnej osoby. Sprawdź wczesne cięcie i krótkie przerwanie wypowiedzi. Jeśli potrzebujesz napisów z wiarygodnymi czasami, uwzględnij dopasowanie i poprawki w budżecie czasowym. Dobra pierwsza transkrypcja przydaje się nawet wtedy, gdy końcowy montaż powstanie gdzie indziej.

Gotowy głos nadaje się do pierwszego testu

Spójrz na drugą część roboczego montażu. Zmienia się nazwa funkcji i trzeba wymienić kwestię lektora w sześciu nagraniach ekranu. Gdy model i sprzęt są gotowe, wygenerowanie nowego ujęcia dźwiękowego lokalnie pozwala tanio sprawdzić efekt. Trudniejsze są spójność i wymowa. Nowe nagranie powinno dobrze brzmieć między sąsiednimi klipami, poprawnie odczytać nazwę produktu i zmieścić się w ujęciu.

Wersja 0.9.0 dodaje Chatterbox do modeli syntezy mowy obsługiwanych przez llama.cpp. W przeglądzie projektu opisano uruchomienia Chatterbox Turbo i Multilingual V3 na CUDA. Sprawdzono głosy domyślne oraz generowanie z nagrania referencyjnego, a do opisu dołączono próbki. To wyniki przeglądu integracji w konkretnym środowisku. W pracy produkcyjnej trzeba jeszcze sprawdzić, czy wybrany głos i język pozostaną spójne w połączeniu z docelowym tekstem i sprzętem. Obsługa Chatterbox i próbki dźwięku od opiekunów projektu

Pocket TTS daje inną opcję. Zgodny model może udostępniać nazwy wbudowanych głosów w polu voices w odpowiedzi serwera na GET /props. Klient może przekazać wybraną nazwę do ścieżki syntezy mowy. Skrypt lub mała aplikacja mogą w ten sposób wypełnić listę wyboru danymi z wczytanego modelu. Pierwszy pilotaż może też korzystać z gotowego głosu, bez pozyskiwania i przechowywania nagrania osoby, której głos miałby zostać odtworzony. Zapisz model i nazwę głosu wraz z eksportem, by kolejny montaż mógł zacząć od tych samych ustawień. Gotowe głosy Pocket TTS

Ilustracja Telli.sh. Odsłuchaj dźwięk przed eksportem. Nazwa wybranego głosu mówi, o co poproszono, a odsłuch pokazuje, co powstało.

Zacznij od krótkiego skryptu zawierającego sformułowania pomijane w zwykłych pokazach. Dodaj kod produktu, zapis adresu lub liczbę z jednostką oraz zdanie, w którym liczy się ton. Wypróbuj trzy osobne wypowiedzi, a potem wygeneruj cały akapit. Głos może brzmieć spójnie w pojedynczych zdaniach, a w dłuższym ujęciu zbyt szybko przeczytać ważne słowo. Poproś osobę znającą język odbiorców o odsłuch bez skryptu, a następnie porównaj to, co usłyszała, z zamierzonym tekstem.

Zapisuj końcowy dźwięk oddzielnie od skryptu i nagrań źródłowych. Jeśli później okaże się, że liczba została odczytana błędnie, poprawisz konkretne ujęcie bez utraty oryginalnego montażu. Jeśli w projekcie uczestniczy już uprawniony lektor, wyraźnie oznacz nagrania lektora i wygenerowane warianty, by jeden materiał nie zastąpił drugiego bez śladu. Gotowy głos jest prostym wyborem, kiedy wystarczy zrozumiała i spójna narracja.

Wersja środowiska to tylko jeden element konfiguracji

Jeśli zespół już używa llama.cpp, wydanie może usunąć powód do zmiany środowiska uruchomieniowego. Nadal potrzebna jest kompilacja zgodna z maszyną docelową, właściwe pliki modelu i wymagane przez model pliki dodatkowe, na przykład projektor multimodalny opisany w integracji Nemotron. Wagi pobiera się osobno i obowiązują je własne warunki. Przed spakowaniem dowolnej części konfiguracji dla innego zespołu lub klienta sprawdź dokumentację środowiska i modelu. Pliki wydania oraz Uwagi konfiguracyjne integracji Nemotron

Pamięć warto mierzyć w trakcie zadania, po zakończeniu ładowania modelu. Rozmiar pliku pokazuje, ile miejsca zajmuje on na dysku. Wykonanie wymaga też pamięci na pracę modelu, bufory zaplecza obliczeniowego i dane pośrednie. Komputer stacjonarny może rozpocząć transkrypcję, a mimo to spowolnić montaż, jeśli oba zadania korzystają z GPU. Laptop może działać dobrze za pierwszym razem, a zwolnić za czwartym z powodu nagrzewania i zadań w tle. Zapisz szczytowe zużycie RAM i, jeśli ma znaczenie, pamięci GPU z otwartym edytorem w konfiguracji planowanej do pracy.

Opiekunowie projektu opisali walidację w zgłoszeniu integracji Nemotron. Użyli nagrań czystej mowy i zbiorów spotkań, określonej kwantyzacji i karty RTX PRO 6000 Blackwell w środowisku testowym. Wyniki pokazują, jak sprawdzono integrację. Przy decyzji o zakupie lub wdrożeniu przetestuj własne nagrania na docelowym sprzęcie. Nawet przy tej samej maszynie zmiana precyzji, języka lub udziału nakładających się wypowiedzi może zmienić proporcję między czasem przetwarzania a nakładem na poprawki. Walidacja i konfiguracja Nemotron

Porównuj wersje w prosty sposób. Kompilacja b12144 z 6 listopada to oddzielne wydanie przedpremierowe, które zmienia rozmieszczenie komponentów modeli typu mixture-of-experts na CUDA. Aby ocenić funkcje dźwiękowe, zacznij od numerowanego wydania z 4 listopada i zachowaj te same pliki modeli oraz ustawienia. Późniejszy test wydania przedpremierowego zapisz jako osobny przebieg. Łatwiej wtedy ustalić, czy zmiana wynika z modelu dźwięku, zaplecza inferencji czy aplikacji. Informacje o wydaniu przedpremierowym z 6 listopada

Przetwarzanie lokalne wymaga precyzyjnego ustalenia, co zostaje na urządzeniu. Jeśli edytor odpyta lokalny serwer, inna aplikacja może nadal wysyłać logi, synchronizować katalog wynikowy lub pobierać zależność. Przed wprowadzeniem wrażliwych nagrań pobierz wymagane programy i wagi na maszynie testowej lub w wyznaczonym kroku przygotowawczym. Potem użyj nieszkodliwego klipu bez połączenia z siecią i sprawdź, które etapy się kończą. Ustal miejsce zapisu oryginału, danych tymczasowych i eksportu. Lokalne środowisko pozwala wykonywać inferencję na urządzeniu, a za pełną ścieżkę danych odpowiada aplikacja.

Wypróbuj jeden projekt na komputerze, z którego faktycznie korzystasz

1. Wybierz dwa krótkie materiały, którymi możesz się podzielić. Nagraj 30–60 sekund rozmowy dwóch osób, z odrobiną nakładających się wypowiedzi i wymyśloną nazwą funkcji. Napisz krótką narrację z tą samą nazwą i jedną trudną do wymówienia liczbą. Używaj tych samych wejść w kolejnych próbach, aby zauważyć skutki zmiany ustawienia.
2. Ustal konkretne wersje środowiska i modeli. Wybierz kod v0.9.0 albo powiązaną kompilację b12110 na swój system. Zapisz źródło modelu, nazwy plików i kwantyzację. W przypadku Nemotron uruchamianego przez llama-server dokumentacja scalonej integracji zaleca --reasoning off, bo domyślny szablon może zwrócić rozumowanie bez transkrypcji. W uwagach wskazano, że multimodalny interfejs wiersza poleceń nie wymaga tego przełącznika. Testuj ten wariant, którego zamierzasz używać. Uwagi o integracji Nemotron
3. Zmierz pierwszy i kolejne przebiegi. Zapisz czas od uruchomienia do wyniku za pierwszym razem oraz czas uzyskania wyniku po wczytaniu modelu. W przypadku transkrypcji podziel czas przetwarzania przez długość audio, by ocenić oczekiwanie przy dłuższym nagraniu. Zapisz szczytowe zużycie pamięci i sprawdź, czy edytor pozostaje responsywny. Przy narracji ważniejszy może być czas między zmianą jednej kwestii a odsłuchaniem nowej wersji.
4. Porównaj błędy według kosztu poprawek. Zaznacz pominięty termin, błędną liczbę, zamianę rozmówców i zdanie, któremu trzeba poprawić czas. Wlicz czas poprawek w czas ukończenia. W narracji sprawdź nazwy, liczby, pauzy i dopasowanie nowego dźwięku do ujęcia. Porównanie powinno uwzględniać gotowy, poprawiony plik obok pierwszego wyniku.
5. Ustal przekazanie pracy przed automatyzacją. Zdecyduj, kto sprawdza transkrypcję, gdzie dopasowuje się napisy i jak oznacza zatwierdzoną narrację. Po udanej pierwszej próbie użyj drugiego klipu. W razie błędu zachowaj wejście i pokaż niepowodzenie w kolejce montażowej, by człowiek mógł wznowić pracę bez powtarzania całej partii.

Do zapisu wyników wystarczą cztery kolumny arkusza: przygotowanie, przetwarzanie, poprawki i akceptacja. Zanotuj powód odrzucenia każdego pliku. Po kilku próbach może się okazać, że lokalny zestaw sprawdza się przy powtarzanych zmianach narracji, a do hałaśliwych wywiadów grupowych nadal potrzeba innego procesu. To użyteczna wiedza. Korzystaj z każdej części tam, gdzie oszczędza czas, i zapisuj sytuacje, w których metoda zapasowa działa lepiej.

Jeśli masz już skuteczny proces transkrypcji, porównaj go na tym samym nagraniu i według tych samych kryteriów. Możesz przenieść tylko łatwiejszą część, na przykład roboczą narrację o niskim ryzyku na stację montażową. Sprawdzony proces napisów może skorzystać ze wspólnej lokalnej integracji później, gdy pojawi się powód do połączenia obsługi modeli, a nowe rozwiązanie spełni dotychczasowe kryteria redakcyjne.

Gdzie wydanie przydaje się najbardziej

Najlepiej zacząć od czynności, którą już powtarzasz. Zespół tworzący poradniki może przepisać robocze ujęcie przed opuszczeniem maszyny montażowej przez plik i wygenerować próbny głos, by sprawdzić tempo. Badacz może uzyskać edytowalną transkrypcję nagrania, nad którym ma kontrolę, poprawić oznaczenia rozmówców i zachować oryginalny dźwięk. Mały zespół programistyczny może przetestować obie ścieżki we własnym interfejsie, o ile pokazuje on wybrany model, wynik i ewentualny błąd.

Najważniejszą możliwością wydania jest ograniczenie przekazywania pracy między specjalistycznymi narzędziami przy zachowaniu osobnej kontroli jakości. Model transkrypcji nadal musi rozpoznać słowa i rozróżnić rozmówców. Model syntezy nadal musi wypowiedzieć skrypt. Montażysta nadal ocenia gotowość pliku. Zmiana polega na tym, że zadania mogą korzystać z jednego zestawu narzędzi do inferencji, a być może również z jednego komputera, którego już używasz.

Jeśli chcesz wrócić do gotowego nagrania razem z transkrypcją i notatkami, prześlij plik do Telli.sh.