Dacă sunteți nou în procesul de conversie a fișierelor audio, atunci multe dintre detalii și modul în care funcționează pot fi puțin confuze atunci când obțineți rezultate neașteptate. Deci, ce faceți pentru a rezolva problema? Postarea de astăzi SuperUser Q & A are răspunsul la o întrebare confuză a cititorului.
Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor Q & A.
Fotografie prin amabilitatea lui Warein (Flickr).
Cititorul SuperUser Arlen Beiler dorește să știe de ce folosesc diferite setări de biți atunci când convertiți un fișier audio produs fișiere care au aceeași dimensiune exactă:
Am convertit un flux audio în trei setări de biți diferite, utilizând ceea ce este, în esență, același format. Au ajuns exact la aceeași dimensiune. De ce asta?
- ffmpeg -i "Likoonl-Q1-All.mp4" -c: v copie -c: a libmp3lame -q: a 1 -b: o 192k "Q1-All-192k.mp4"
- ffmpeg -i "Likoonl-Q1-Toate.mp4" -c: v copie -c: a libmp3lame -q: a 1 -b: o 160k "Q1-All- 160k.mp4"
- ffmpeg -i "Likoonl-Q1-All.mp4" -c: v copie -c: a libmp3lame -q: a 1 -b: a 128k "Q1-All-128k.mp4"
Cum a reușit utilizarea setărilor de biți diferite să producă fișiere de aceeași dimensiune exactă?
Contribuitor SuperUser slhck are răspunsul pentru noi:
Pentru că tu ești -q: o (care este setarea VBR a LAME). Când utilizați -q: o, setarea CBR -b: o nu va avea nici un efect. Dacă vă uitați în ghidul de codare MP3 din Wiki-ul FFmpeg, veți găsi valorile posibile pentru -q: o cu rata medie de biți corespunzătoare.
Din motive de exhaustivitate, aici este partea relevantă din libmp3lame.c (qscale este numele lung al lui q):
Aveți ceva de adăugat la explicație? Sunați în comentarii. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.
