-
|
| .
|
|
|
|
Con gli anni migliora la tecnologia e miglioriamo anche noi.
Con un misto di entrambe, abbiamo migliorato il nostro metodo con cui applichiamo la Loudness Correction a -24LUFS a One Piece, per essere ancora più conformi allo standard EBU R128.
Cordiali saluti,
FranceBB
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 4
- Status
- Offline
|
|
Chiedo scusa, da quando avete annunciato di utilizzare un nuovo metodo per la LoudnessCorrection sto riscontrando seri disturbi nell'audio degli episodi; dalla 847 in poi sia HD che FHD. In pratica negli scontri oppure punti in cui si accavallano molte voci oppure in alcuni punti della sigla (credo che accade quando di supera una certa soglia di dB) l'audio risulta molto disturbato/gracchiante; come mai accade questo?
Ho segnalato anche sulla pagina FB senza ricevere risposta.
|
|
|
| .
|
-
|
| .
|
|
|
|
Mi dispiace che tu lo abbia segnalato su facebook e che nessuno ti abbia dato una risposta, tuttavia lo staff che abbiamo predisposto alle risposte su facebook è uno staff non tecnico che risponde a diverse tipologie di problematiche e non hanno fatto escalation del problema verso di noi.
Ok, adesso torniamo a noi.
La loudness correction semplicemente dovrebbe andare ad analizzare la traccia audio ed aggiustarla in modo che sia conforme allo standard -24LUFS. Il processo prevede semplicemente abbassare ove troppo alto ed alzare ove troppo basso, per garantire una traccia consistente durante tutto l'episodio. Certo, esplosioni ed effetti sonori tipo il Jet Gatling Gum saranno più forti rispetto ad un parlato, tuttavia non saranno eccessivamente forti (i.e non ti spaccheranno i timpani).
Ora... quello che noti mi fa pensare ad una cosa molto brutta che non dovrebbe accadere: il clipping.
Credo che per qualche motivo, quando la loudness supera di molto i -24LUFS, venga fatto clipping, ovvero vengano troncate alcune frequenze. L'idea era di fare un soft clipping ed evitare di troncare, semplicemente abbassando ove possibile e troncando il meno possibile e solo su acuti veramente troppo alti.
Hai fatto benissimo a segnalarlo e penso proprio di aver capito che cos'è che sta causando il clipping. Provo ad impostare un parametro più permissivo e vedere. Magari, la media rimane di -24LUFS ma permetto all'audio di farlo andare a picchi di -18LUFS ogni tanto; questo dovrebbe risolvere il problema.
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 4
- Status
- Offline
|
|
Mi sono documentato un po' sul fenomeno del clipping per vedere se effettivamente si trattasse di questo, e credo proprio che la risposta sia affermativa! Dall'episodio 847 sono molto frequenti questi disturbi audio, mi meraviglio di essere stato il primo ad averlo segnalato sul forum... forse ad un orecchio poco attento non risulta evidente e si confonde con gli effetti audio dei combattimenti.
Comunque ti ringrazio per la disponibilità e la precisione della risposta!
Una curiosità: è stata applicata la stessa tecnica per la nuova puntata di DB Heroes?
|
|
|
| .
|
-
|
| .
|
|
|
|
Sì, è stata fatta la stessa identica cosa anche per le altre serie.
L'ho comunicato a Mugi e dalla prossima settimana utilizzeremo LRA14 al posto di LRA1 per essere un po' più permissivi nella variazione e risolvere il problema.
Per quanto riguarda il fatto che tu sia stato il primo, non mi meraviglia: la maggior parte degli utenti vede l'episodio su TV con audio ambientale; vista la poca qualità delle casse integrate delle TV di questi tempi e considerando che quasi nessuno ha più un Home Theatre e che pochi hanno le soundbar, non ci hanno fatto caso.
Effettivamente, anche a me all'inizio era sfuggito perché ho effettuato un controllo spot check molto veloce ed in cassa, ma appena ho messo le cuffie me ne sono accorto.
Fammi sapere prossima settimana. 
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 9
- Status
- Offline
|
|
Buongiorno, come segnalato dall'utente GennaroG3m, anch'io sto riscontrando per one piece dall'episodio 847 dei problemi all'audio. Ho appena scaricato l'ultimo episodio rilasciato da voi, l'856, e riscontro ancora lo stesso problema all'audio. Spero che possa essere risolto al più presto e che vengano corretti anche gli episodi precedenti.
Mi scuso con lo staff nel caso questa non sia la sezione adatta a queste segnalazioni, ma ho scritto qui in maniera da poter continuare il discorso iniziato la settimana scorsa dall'utente GennaroG3m
|
|
|
| .
|
-
|
| .
|
|
|
|
Ho scritto giorni fa a Mugi i nuovi parametri da utilizzare. Che li abbia utilizzati o meno dipende da lui, ma probabilmente non lo ha fatto.
Gli ho scritto di nuovo.
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 9
- Status
- Offline
|
| |
Buongiorno, ho appena concluso la visione dell'episodio do One Piece rilasciato oggi, l'857, e segnalo il persistere del problema all'audio. Penso che sia necessario rivedere bene la codifica audio da cima a fondo in quanto il tutto persiste ormai da 11 episodi. e se posso dare un consiglio: considererei la possibilità di rilasciare una versione con l'audio originale senza questa codifica in modo da permettere a chiunque di vedere gli episodi senza difficoltà, in quanto i PC che non siano di ultimissima generazione non supportano la codifica audio attualmente utilizzata. Detto questo auguro allo staff un buon fine settimana.
|
|
|
| .
|
-
|
| .
|
|
|
|
Ho l'impressione che mugi stia facendo qualcosa di diverso da quello che faccio io in studio.
Adesso ti passerò tre sample: il primo è l'original a -10LUFS, il secondo è il limiter in cui viene solo applicata una limitazione a -24LUFS ed il true peak a -2 di massima ed il terzo è la Loudness Correction completa.
Voglio che tu mi dica se il problema si presenta perché io non lo noto.
Se non si presenta, vuol dire che mugi sta facendo qualcosa di diverso da quello che faccio io.
Nello specifico, l'audio a 48'000Hz viene processato a 24bit PCM, diviso in 18 sotto-bande di frequenza, ciascuna filtrata individualmente ed infine ri-messe insieme per creare l'audio finale a -24LUFS.
Nello specifico abbiamo:
Band # f (low) f (high)
1 0 Hz 65 Hz
2 65 Hz 93 Hz
3 93 Hz 131 Hz
4 131 Hz 185 Hz
5 185 Hz 262 Hz
6 262 Hz 370 Hz
7 370 Hz 523 Hz
8 523 Hz 740 Hz
9 740 Hz 1047 Hz
10 1047 Hz 1480 Hz
11 1480 Hz 2093 Hz
12 2093 Hz 2960 Hz
13 2960 Hz 4186 Hz
14 4186 Hz 5920 Hz
15 5920 Hz 8372 Hz
16 8372 Hz 11840 Hz
17 11840 Hz 16744 Hz
18 16744 Hz 22000±Hz
Original
Limiter
Loudness
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 9
- Status
- Offline
|
| |
Buonasera, rispondo alla domanda fattami dallo staffer FranceBB: dopo aver ascoltato tutte e tre le tracce, ti dico che nella "original" si conserva tutto il dinamismo della canzone ed è perfetta, nella "limiter" la traccia audio risulta piatta e non si distinguono nè alti nè bassi, infine nella "loudness" il suono si sente piatto e ovattato
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 4
- Status
- Offline
|
|
Nonostante queste segnalazioni il problema persiste ancora, sia negli episodi di One Piece sia negli episodi di DragonBall Heroes. Lo stesso episodio è stato testato su differenti pc, smartphone e tv (con le cuffie e senza) e in tutti i casi mi è risultato FASTIDIOSO guardarlo a causa di stridii continui nell'audio nonché a causa di un audio generale poco chiaro (sembra di guardare l'episodio sott'acqua in alcuni punti, senza contare i continui cambi di volume anche nella stessa frase mentre parla lo stesso personaggio...). Certo su alcuni dispositivi si nota di più, su altri di meno, ma il problema per la codifica audio c'è. Che siano parametri in dB sbagliati, che sia il "clipping" come mi è stato spiegato diverse settimane fa, che sia scarsa comunicazione tra i membri dello staff (dato che ho letto sopra che uno dice una cosa e chi fa le puntate ne fa un'altra) non mi è dato saperlo. So per certo che dall'episodio 847 di One Piece e gli ultimi 2 episodi di DragonBall Heroes presentano questo fastidioso problema audio che allo stato attuale non è stato risolto.
Fiducioso che possiate risolvere questo problema e migliorare la qualità degli episodi rilasciati vi auguro un buon lavoro.
Grazie dell'attenzione.
|
|
|
| .
|
-
|
| .
|
|
|
|
Ragazzi,
mi avete fatto un bello scherzo. xD
Ho capito il problema (questa volta davvero) ed ora vi spiego.
Praticamente, quello che mi ha tratto in inganno è che pensavamo tutti fosse la loudness correction, quando questa in realtà non c'entra nulla, è semplicemente la compressione in AAC.
Per il seguente test ho utilizzato un master file in PCM non compresso che avevo a disposizione.
@GennaroG3m e @Fiorenzo Romano... ecco il link: Link
Nel file rar troverete i seguenti file:
1) test.wav
Questo è il file master in PCM non compresso con una loudness altissima che va addirittura oltre i -10LUFS.
2) Loudnorm-24LRA-14TP-2.wav
Questo è il file encodato in PCM non compresso 48'000Hz con la nuova loudness correction a -24LUFS, no clipping.
Si sente perfettamente.
3) Normalize(0.22).wav
Questo è il file encodato in PCM non compresso 48'000Hz con la vecchia loudness correction a -24LUFS, no clipping.
Si sente perfettamente.
4) Loudnorm-24LRA-14TP-2 (AAC 320kbits).m4a
Questo è il file encodato in AAC lossy 320kbit/s con la nuova loudness correction.
Gli artefatti che si sentono NON sono dovuti al clipping, bensì al fatto che l'AAC non riesce a comprimere tutti i souni contemporaneamente.
Nella tesi di ricerca che pubblicai all'università nel 2016 ho descritto come le frequenze relative agli applausi siano tra le più difficili da comprimere a livello di codec.
In questo caso l'AAC - che utilizza la trasformata discreta del coseno - non è stato in grado di comprimere correttamente tutti i suoni ed ha prodotto degli artefatti, come si evince - ad esempio - al minuto 08.58 circa.
5) Normalize(0.20) (AAC 320kbits).m4a
Questo è il file encodato in AAC lossy 320kbit/s con la vecchia loudness correction.
Gli artefatti che si sentono NON sono dovuti al clipping, bensì al fatto che l'AAC non riesce a comprimere tutti i souni contemporaneamente.
Anche in questo caso, al minuto 08.58 circa si può sentire come questi siano molto presenti.
6) Loudnorm(AC3 384kbits).ac3
Questo è il file encodato in AC3 lossy 384kbit/s con la nuova loudness correction.
Pur non essendo così cristallino come un PCM non compresso, la quantizzazione effettuata non crea artefatti identificabili.
7) Loudnorm(AAC 550kbits).aac
Questo è il file encodato in AAC lossy 550kbit/s con la nuova loudness correction.
Pur non essendo così cristallino come un PCM non compresso, la quantizzazione effettuata non crea artefatti identificabili.
In altre parole, non c'è assolutamente niente di male con la vecchia loudness correction né con la nuova loudness correction.
Semplicemente l'AAC ha bisogno di più bitrate per poter riprodurre correttamente tutte le frequenze ed evitare artefatti.
Ovviamente non posso darvi un file PCM perché sarebbero 200 MB di audio ad episodio e non è fattibile.
Quello che posso fare però è aumentare il bitrate dell'AAC in modo che sia basso nei punti di silenzio o meno importanti e possa salire fino a 550 kbit/s nei punti più importanti e con più suoni.
Attualmente è limitato a 320kbit/s.
Grazie a tutti.
Cordiali saluti,
FranceBB
|
|
|
| .
|
-
|
| .
|
- Group
- Member
- Posts
- 4
- Status
- Offline
|
|
Ti ringrazio per la risposta dettagliata, provvedo a scaricare l'archivio e ad ascoltare attentamente le varie tracce! Intanto aspettiamo l'episodio di domani con il nuovo bitrate e vediamo cosa succede sperando che si sia trovato e risolto il problema! Siccome i problemi sono iniziati con l'episodio 847 pensavo fosse dovuto alla nuova Loudness Correction... 😕
Finalmente potrò godermi gli episodi senza quel fastidiosissimo stridio di fondo ahahah
|
|
|
| .
|
12 replies since 1/9/2018, 04:26 1636 views
.
.
.
.png)
Contacts
Web