¿Por qué la tasa de bits variable todavía tiene una tasa de bits especificada?

Tengo entendido que el algoritmo vorbis usa una tasa variable de codificación.

Entonces, al codificar videos con audio en formato vorbis, ¿por qué Handbrake me pide una tasa de bits? ¿Qué hace Handbrake cuando elijo un bitrate de 160, digamos, en el apartado de audio?

Publiqué esta pregunta en Super User SE, pero nadie me respondió: [link] superuser.com/questions/729591/… .
No puedo hablar de vorbis, pero en general, la tasa "variable" no significa "ilimitada". En todos los casos que conozco, la codificación VR utiliza una tasa de bits objetivo que es la tasa que, si se promedia sobre la longitud total, sería equivalente a una tasa de bits fija durante la misma duración.

Respuestas (2)

Puede ver la tasa de bits en este caso como un objetivo de calidad. No codificará el audio estrictamente a esa tasa de bits, pero intentará codificar el audio de manera que siempre esté "cerca" de la tasa de bits especificada.

Por lo general, puede traducir ciertas tasas de bits a un nivel de calidad específico que se puede comparar con lame "V0", "V2", etc. Configuraciones de VBR, estos valores predeterminados no definen una tasa de bits específica, pero los archivos codificados con estas configuraciones terminar en cierto "rango de velocidad de bits". El codificador codificará el audio en torno a una tasa de bits específica, pero subirá o bajará dentro de un cierto umbral.

No tiene mucho sentido tener ratas de bits presentes en lugar de los objetivos de calidad de Vorbis, pero asumo que el freno de mano hace esto porque todos los demás códecs que ofrece usan velocidades de bits. La mayoría de los usuarios están acostumbrados a las tasas de bits y pueden asociarlas a un nivel de calidad aproximado. A diferencia de Vorbis, "q5" o "q9", que solo puede traducir a una diferencia de calidad relativa entre los diferentes niveles (si no está acostumbrado a usar este códec), pero no sabrá con qué termina realmente.

Wikipedia tiene una buena tabla para los niveles/configuraciones de calidad de Vorbis: http://en.wikipedia.org/wiki/Vorbis#Technical_details (a la derecha)

Calidad Tasa de bits nominal Fundación oficial Xiph.Org Vorbis aoTuV
beta 3 y posterior

  • -q-2 no disponible 32 kbit/s
  • -q-1 45 kbit/s 48 kbit/s
  • -q0 64 kbit/s
  • -q1 80 kbit/s
  • -q2 96 kbit/s
  • -q3 112 kbit/s
  • -q4 128 kbit/s
  • -q5 160 kbit/s
  • -q6 192 kbit/s
  • -q7 224 kbit/s
  • -q8 256 kbit/s
  • -q9 320 kbit/s
  • -q10 500 kbit/s

Para las codificaciones CBR, la tasa de bits siempre se mantiene en la tasa de bits especificada, independientemente de si es necesaria. Para la codificación VBR, la tasa de bits es un objetivo promedio, sin embargo, el flujo de medios utilizará más o menos tasa de datos cuando sea necesario, pero intentará promediar el objetivo.

Es por eso que ve 1 paso y 2 pasos VBR. 2 pasadas VBR primero hace una pasada para estimar dónde se necesitarán más o menos datos y luego hace una segunda pasada para aprovechar al máximo la tasa de datos disponible. 1 pase hace muchas más adivinanzas.

Para ver un ejemplo de cómo funciona esto, digamos que teníamos un video que tenía 10 segundos de acción rápida seguidos de 10 segundos de una imagen fija.

Con CBR, se usaría la misma velocidad de datos todo el tiempo, los 10 segundos de imagen fija serían de una calidad increíblemente alta ya que nada cambia, pero la acción se desmoronaría porque cambia demasiado.

Con 1 paso VBR, el algoritmo se ajustaría para usar más datos para el alto nivel de acción, pero podría limitarse ya que todo el video podría ser así. Luego, cuando llegaba a la toma fija, no usaba casi nada, pero no alcanzaba la tasa promedio porque no necesitaba espacio de almacenamiento.

Con VBR de 2 pases, el primer pase descubriría que no hay movimiento al final, por lo que durante el segundo pase, se usaría una gran cantidad de velocidad de datos para manejar el movimiento muy bien y luego se usaría muy poca para la imagen fija. imagen, la tasa de datos promedio se vería afectada y la parte de alto movimiento del video tendría la calidad más alta de cualquiera de las codificaciones, mientras que la parte fija realmente no sufriría.