MPC: ANTAGONISTI FREQUENCY
(mumble, 31-05-2002)

I frequency codec non sono certo tutti uguali, ce ne sono alcuni che stanno una spanna sopra gli altri, in particolare mi riferisco ad  Advanced Audio Coding (AAC), il vero successore di mp3 (altro che quel "giocattolo" di mp3pro), e' un formato standardizzato (disponibile sia in MPEG-2 che in MPEG-4, sebbene con diversi "profili").
E' l'unico formato frequency che attualmente possa competere con MPC
(e superarlo, se utilizzato al massimo delle sue specifiche, dunque mettendo mano al suo stato dell'arte che attualmente, visto il costo delle licenze, rimane esclusivamente nelle mani di Fraunhofer, Dolby e "parenti altolocati"), ma deve essere un AAC di implementazione-fattura ottima, infatti puo' esserci una notevole differenza di risultati qualitativi tra una buona ed una cattiva implementazione di AAC.
Per "competere con MPC", si intende sempre considerando il miglior campo d'azione di MPC, cioe' da bitrate >= a 160kbps (questo potrebbe  cambiare in futuro, vista la recente strada intrapresa da Klemm tesa ad ottenere una rimarchevole qualita' per MPC anche attorno ai canonici 128kbps), ovvio che se si comincia a scendere di brutto con il bitrate, si iniziera' a giocare "in casa" dei frequency audio codec (ma non vuol dire che questi possano ottenere la "trasparenza" con l'originale a bassi bitrate, quella dei "128kbps = qualita' CD" e' una balla pure per gli attuali AAC, figuriamoci per gli inferiori mp3, mp3pro, wma, e bla bla..).

Da menzionare il fatto che ottimizzare AAC e' compito piuttosto arduo, come sa bene Ivan Dimkovic, sviluppatore dell'attuale migliore implementazione (disponibile all'utente finale) di AAC, cioe' PsyTEL AAC, ormai qualitativamente >= al Liquifier di Liquid Audio.
PsyTEL AAC e' ottimo ma non ancora al livello di MPC, sempre considerando il target di MPC, ovvero bitrate da circa 160kbps in su.
A questi bitrate, l'attuale superiorita' di MPC rispetto a tutti gli altri, PsyTEL AAC incluso (soprattutto tenendo conto di alcuni campioni che NON POSSONO essere un problema per la natura stessa di MPC , ma
causare sicuramente dropouts e/o pre/post echo, piu' o meno avvertibili,
anche in frequency codec abbastanza ottimizzati), e' stata piu' volte
ammessa anche dallo stesso Ivan Dimkovic (mi riferisco a post pubblici
di vari forum, sopratutto il vqf forum).
Pero' qua ormai si gioca ad alti livelli per la codifica lossy, quindi margini risicati (per l'attuale tecnologia) e percio' nell'eventualita' di casistiche che facessero emergere eventuali differenze qualitative tra i due codec summenzionati, raramente queste sarebbero notevolmente marcate.

Purtroppo, nonostante AAC sia standardizzato, rimane e rimarra' per lungo periodo un formato blindato per noi utenti finali o perlomeno non sara' sfruttabile-gestibile in una maniera cosi' permissiva e a tutto campo come e' accaduto per mp3 (non rifaranno il medesimo errore).
Alcuni suoi sostenitori decantano il fatto che AAC sia piuttosto supportato dai player hardware portatili, ecc.. Questo e' falso, perche'  quello che e' supportato non e' altro che stream AAC "manipolato- crittografato" (uno degli effetti "collaterali" di questo formato  blindato e strettamente controllato da Dolby e compagnia; un esempio di  questi tipi di AAC sono quelli creati dall'encoder Liquifier di Liquid  Audio), insomma un AAC che sta all'interno di "contenitori" proprietari,  di conseguenza su quei portatili non e' possibile riprodurre AAC ISO "in  chiaro", dunque non e' possibile per esempio riprodurre dei file fatti da  noi con PsyTEL AAC. L'unica eccezione a questo mi sembra sia il player  Philips Expanium (limitato pero' al low complexity profile di MPEG-2 AAC) che pero', vista la sua scarsa qualita' generale (da quello che mi hanno detto alcuni suoi proprietari), non ne rende molto conveniente l'acquisto.
Ricordo poi che il massimo profilo qualitativo di AAC, ovvero il Main Complexity profile, richiede una NOTEVOLE potenza computazionale, ecco
anche il perche' quasi nessuno lo utilizza (si preferisce usare il Low complexity profile).
Pure qua MPC la fa da padrone: non solo e' eccezionale in qualita', ma richiede potenza computazionale inferiore anche a quella necessaria per mp3 (dunque, per esempio, un portatile con potenza di DSP appena sufficiente per la decodifica mp3, spesso per un discorso di consumi, con un aggiornamento firmware sarebbe in grado di riprodurre anche i file MPC, ma sicuramente non sarebbe in grado di riprodurre i file AAC).

Da menzionare anche che, sia nei tempi di codifica che in quelli di decodifica, MPC e' il piu' veloce (piu' veloce di Ogg Vorbis, di PsyTEL AAC, di Lame mp3, ecc.).

Sfortunatamente anche il mondo che ruota attorno ad AAC non e' molto attivo, a differenza delle attivita' frenetiche che si muovono attorno ad MPC.
Queste infatti non sono da sottovalutare e spesso possono portare dei contributi di rilievo, mi riferisco ad esempio a Replaygain, alla possibilita' di dare direttamente in input ad MPC dei file lossless, ecc.. Attualmente la velocita' e flessibilita' di sviluppo di MPC non sono paragonabili alla staticita' che si "respira" in casa AAC (ma questo non vuol certo dire che le cose non possano cambiare).

La cosa triste e' che in questo campo invece di AAC sta passando sotto
i riflettori perfino un formato non certo di alta' qualita' come mp3pro, spacciato come successore di mp3 (non e' vero, il successore ufficiale-commerciale e' AAC; tra l'altro la Spectral Band Replication,
SBR, utilizzata in mp3pro, e' disponibile pure in AAC, ma questa SBR
serve piu' per ottenere una certa "gradevolezza" uditiva a bassi bitrate, come ad esempio 64 kbps, piuttosto che l'ottenimento di una maggior trasparenza con l'originale).
Queste informazioni ingannatrici stanno facendo proseliti soprattutto
tra i disinformati (inclusi alcuni articolisti di varie riviste informatiche) e i non interessati alla materia.

Se vogliamo schematizzare l'attuale situazione-classifica dei migliori perceptual audio codec, "migliori" intesi come QUALITA' DI RISULTATO ORIENTATO ALLA TRASPARENZA NEI CONFRONTI DELL'ORIGINALE (dunque sono esclusi codec progettati unicamente per avere una "certa soddisfazione" a bassi bitrate, come mp3pro, wma, vqf, ecc.), ma sempre tenendo conto dell'attuale bitrate target di MPC (>=160 kbps), avremo quanto segue (qualita' in ordine decrescente):

1- MPC (MusePaCk)
2- PsyTEL AAC
3- Ogg Vorbis/Lame mp3

La situazione della terza posizione e' molto soggettiva.
A differenza dei sostenitori accaniti del "formato libero e aperto",   secondo me Ogg Vorbis attualmente non e' sempre in grado di prevalere su un attuale Lame mp3 utilizzato al meglio (ovvero con i preset di Dibrom), anche perche' ci sono ancora discreti problemi di pre-echo (bisogna pero' ammettere che Ogg non ha certo avuto tutto il tempo di ottimizzazione-sviluppo che ha avuto Lame).
Ogg Vorbis e' un frequency codec open-source/patent-free.
Attualmente e' in versione Release Candidate 3 (RC3) e la futura RC4 dovrebbe presentare miglioramenti soprattutto ai bassi bitrate.
Ha alcune caratteristiche interessanti (come il bitrate peeling) che pero' saranno adottate in futuro. Purtroppo lo sviluppo procede lentamente, anche perche' al momento c'e' solo una persona (Monty) che sta lavorando al suo kernel.
Ha sicuramente dei grandi margini di miglioramento, soprattutto tenendo conto della futura possibilita' di adottare la tecnologia wavelet (che dovrebbe prendere il meglio dei mondi frequency e subband).
C'e' da dire che molti dei suoi supporter sono contraddistinti da una certa faziosita': il voler vedere a tutti costi un progetto "open" (sicuramente essere "open" ha degli innegabili vantaggi) primeggiare o competere qualitativamente alla pari con altri, ottenebra una certa loro capacita' di giudizio serena ed imparziale.
A volte non vogliono vedere, o meglio ascoltare, cio' che non puo' essere contraddetto (come alcune problematiche dell'attuale Ogg Vorbis messe in evidenza anche da certi campioni postati sull'hydrogen audio forum, in contrapposizione alla quasi totale assenza di campioni che possono mandare MPC in crisi).

Questi tre (MPC, AAC e Ogg Vorbis) sono senza alcun dubbio i tre formati al TOP della codifica lossy (ogg vorbis perlomeno nell'immediato futuro) e percio' converra' tenerli sotto stretta osservazione.
Da menzionare il vantaggio che hanno nel non dover preoccuparsi di una
qualsiasi retro-compatibilita', a differenza di Lame, che per migliorare deve continuamente fare i salti mortali, pena la perdita della compatibilita' mp3 (ecco perche' Lame non potra' mai andare oltre un certo limite).

Lame dovreste conoscerlo tutti, e' il miglior codec per quanto riguarda MP3 (ormai ha raggiunto e spesso superato il miglior Fraunhofer anche   sui 128kbps), ma attenzione, se non lo si usa con i preset --alt-preset di Dibrom (Darin Morrison), non sara' utilizzato al meglio.
Ad esempio, un file audio encodato con Lame 3.91, non vuol dire che sia
stato creato utilizzando le massime potenzialita' esprimibili da quella versione di Lame se si e' utilizzata la sua modalita' di default, cioe' la modalita' che non usa i preset --alt-preset, dunque che non usa delle impostazioni di qualita' intensamente e lungamente rodate tramite innumerevoli test uditivi da parte di persone abituate e preparate a cimentarsi in queste procedure, dunque che usa ancora la psicoacustica gpsycho (invece della migliore nspsytune adottata negli
--alt-preset; il tutto verra' rivisto appena Naoki Shibata rilascera' nspsytune 2).
Uno pensera' al perche' l'orientamento e la documentazione ufficiale di Lame non verta di default (e non spinga con forza) sugli --alt-preset.
Personalmente, dopo aver assistito ad alcune discussioni, penso che
tutto questo sia dovuto all'ottusita' di alcuni sviluppatori "conservatori" di Lame (Dibrom e' entrato solo recentemente), ma forse e' solo una questione di mera ripicca nei confronti di qualcuno (Dibrom, che e' anche un agguerrito supporter MPC) che in pochi mesi e' riuscito a fare piu' di quanto abbiano fatto loro nell'arco di un anno e mezzo (e oltre).

Questo e' anche uno dei motivi (--alt-preset non di default) che mi spinge sempre a SCONSIGLIARE l'uso della dll di Lame (lame_enc.dll), USATE SEMPRE l'eseguibile (lame.exe).   Fregatevene se la dll sembra piu' comoda, se e' disponibile di serie con alcuni ripper e anche se e' disponibile nella versione ufficiale.
Sulla dll non c'e' mai stato il controllo che c'e' sull'eseguibile, spesso si sono riscontrati vari bug che nell'eseguibile non c'erano, c'e' un minor controllo su CHI compila e COME/CON COSA compila, e'  decisamente meno flessibile dell'eseguibile e, come quest'ultimo (purtroppo), di default non e' impostata sugli --alt-preset (percio' un newbie potrebbe usare Lame per mesi e mesi senza mai usarlo al max delle sue potenzialita', un esempio? Ancora oggi c'e' gente che utilizza Lame NON SOLO senza utilizzare gli --alt-preset, ma addirittura usando il vbr di default della dll, cioe' mthr, piu' veloce ma qualitativamente leggermente inferiore a quello adottato dall'eseguibile).

I preset --alt-preset sono stati creati anche e soprattutto per evitare "seghe mentali" che a volte potrebbero essere qualitativamente controproducenti se maneggiate da neofiti e questo vale soprattuto nel caso di un programma come Lame, la cui liberta' e flessibilita' sono decisamente "pericolose" in mano a chi non sa quello che sta facendo. E' altamente sconsigliato modificare questi --alt-preset perche' dietro di loro si celano tecniche-impostazioni spesso l'una in funzione dell'altra: il tutto e' stato pensato (e piuttosto rodato) per lavorare
"in simbiosi".
Ad esempio, ci sono alcuni che, pensando alla teoria e/o a vecchie versioni di lame, ai medi-alti bitrate disattivano il joint-stereo negli --alt-preset pensando di aumentare la qualita' e/o minimizzare certi  rischi: all'atto pratico spesso questo e' esattamente il contrario, come ampiamente dimostrato a suo tempo con molti campioni (e relativi listening test) e relative discussioni sui vari forum. Ma forse e' meglio lasciar parlare il creatore di questi --alt-preset (Dibrom):

Posted by Dibrom on May 28, 2002 10:20 AM
---------------------------------------------------------------------
Joint stereo does not degrade, enhance, or otherwise modify the
soundstage.

At least, not in the LAME alt-presets. If you ever heard an artifact from joint stereo (believe me, in LAME, there are FAR more artifacts in stereo mode.. even in high bitrates.. try fatboy for a good example), it wouldn't sound like a collapsed sound stage anyway. The artifacts in the non-alt-preset joint stereo (note: this is FIXED in the   --alt-presets) are related to the infamous ringing.. and really don't have an effect on the soundstage itself.

People seem to think that just because there is a bug in the Fhg encoders which cause this, that somehow it applies to joint stereo everywhere else. This is completely wrong.  

However, if someone has actually found a problem (hasn't happened so far), and they aren't just speculating about how joint stereo *should* be inferior somehow, then I'd certainly be interested to hear about it..

People who are using -ms with the --alt-presets are really wasting their
time and missing the point. Sorry to say, but you WILL get lower quality
this way.

__________________
- Dibrom
---------------------------------------------------------------------

Alcuni suggerimenti per usare al meglio Lame:

--alt-preset standard nel caso si voglia un vbr con il miglior rapporto qualita'/dimensione file.

--alt-preset standard -Y nel caso che il precedente preset avesse generato un file con bitrate (e conseguente dimensione del file) che voi, per le vostre necessita', ritenete esagerato (-Y disattiva lo sfb21 noise shaping, il risultato pratico e' che verranno tralasciate maggiormente le frequenze superiori ai 16kHz).

--alt-preset <bitrate> per avere un abr che "lavori" sul bitrate
indicato..

Per esempio, nel caso abbiate un portatile con memoria a stato solido
(come il mio), un'ottima stringa (se il vostro decoder mp3 non e' buggato, l'abr lavorera' senza alcun problema) potrebbe essere:

--alt-preset 130 --scale 1

(tale stringa corrisponde a
--abr 130 -h --nspsytune --athtype 2 --lowpass 17.5 --ns-bass -6).

Lo --scale 1 serve per disattivare la normalizzazione implicita (--scale 0.93) nel summenzionato preset. Questo perche' per normalizzare e/o eliminare eventuale clipping e' decisamente meglio farlo tramite un approccio totalmente senza perdita qualitativa, dunque una volta creati gli mp3 conviene usare MP3Gain che implementa i concetti di ReplayGain.

Maggiori informazioni sugli --alt-preset si possono ottenere digitando al prompt dei comandi la seguente linea: lame --alt-preset help|more


Visto che ci sono, vediamo come utilizzare il grabber EAC affinche' le tracce audio estratte siano automaticamente compresse in mp3 utilizzando  gli --alt-preset di Lame 3.90.2 (tramite l'eseguibile "lame.exe" e non tramite la dll; in questo esempio, come impostazione qualitativa verra' usata --alt-preset standard), la versione piu' sicura e ufficiale quando si tratta di usare ESCLUSIVAMENTE gli --alt-preset di Dibrom.

Per prima cosa bisogna recarsi alla sezione "External Compression" (menu "EAC"-->"Compression Options"-->"External Compression")

"Parameter passing scheme": "User Defined Encoder" (e NON "LAME MP3
Encoder").
"Use file extension": .mp3
"Program, including path, used for compression": path completo
dell'eseguibile "lame.exe".
"Additional command options": --alt-preset standard --verbose %s %d
"Bit rate": nun ce ne frega niente ^_______^
"Use CRC check": non attivo

"Add ID3 tag": attivo (in questo caso, nella sezione "ID3 Tag" e'
consigliabile attivare "Use ID3V1.1 tags instead of ID3V1.0 tags" e
consiglierei di disattivare
"Additionally write ID3V2 tags, using a padding of" e
"Use ID3V2.4.0 tags instead of ID3V2.3.0 tags". Il perche' sia
qualitativamente salutare non usare mai ID3v2.x, soprattutto con MPC,
e' spiegato qui.

In verita' anche con mp3 non converrebbe usare ID3v2, ma visto che
a molti frega di piu' mettere un maggior numero di informazioni
descrittive nei file mp3 piuttosto che preoccuparsi di non creare le
condizioni che potrebbero metterne a rischio l'integrita', fate
come vi pare, di mp3 rovinati ce ne sono in giro gia' tantissimi.
Con le impostazioni summenzionate, verranno generati file mp3 con impostazione qualitativa --alt-preset standard.
Il --verbose e' per i curiosoni, dunque se non interessa e/o si ha  attivata l'opzione "do not open external compressor window" (menu Tools),  si puo' tranquillamente tralasciare.

Ultima cosa: visto che anche per mp3 e' disponibile uno strumento (MP3Gain) che implementa i concetti di Replaygain (per maggiori informazioni leggete la parte finale dell'altra mia guida inerente la creazione di file MPC tramite EAC), usate questo per normalizzare gli mp3 o per annullare eventuale clipping, dunque NON usate alcuna opzione di normalizzazione (per peak level o RMS) presente nei vari programmi di audio editing (come CoolEdit, WaveLab, SoundForge, ecc.)
e nei vari ripper (percio' in EAC NON attivate l'opzione "Normalize",
presente in menu "EAC"-->"EAC Options"-->"Normalize").



mumble (night_calls@gmx.net)
Fingerprint: 7972 C6C8 8837 6A80 E1CF 7A64 146E F555 F2BE 9A31

    Ritorna alla pagina principale

Ritorna alla pagina Musepack