Quemar el master....

Un CD que hice hace unos años, los datos del duplicado

General Information
Drive: SONY DVD RW DW-Q120A
Firmware: PYS3
Disc: Audio CD
Selected speed: Maximum
C1 errors
Maximum: 177
Average: 2.61
Total: 9243
C2 errors
Maximum: 0
Average: 0.00
Total: 0
Jitter: n/a
Scanning Statistics
Elapsed time: 2:30
Number of samples: 3532
Average scanning interval: 1.00 sec
Glitches removed: 2

" por lo visto al analisis de trama lo llaman BLER"

Un apunte, el BLER se refiere exactamente al analisis de los bloques de la trama. BLock Error Rate es la tasa de error por bloque, lo cual es mucho mas interesante que el BER que es el Bit Error Rate. Los datos en el CD no se escriben bit a bit, si no que se escriben por bloques, por lo tanto es mucho mas interesante conocer la tasa de bloques erroneos que la tasa de bits erroneos. El BLER no es unico y exclusivo del CD, otros sistemas usan al analisis de error contabilizando los bloques erroneos en vez de los bits erroneos.
Que siga la fiesta

fourier escribió:

Claro man, pero tu lo que obtienes es la reconstruccion, tras la correccion de los errores realizadas por el sistema de correccion, las pruebas estas las suelen hacer en las plantas analizando directamente la trama extraida previa a la correcccion y luego miran a ver de esos errores los que se pueden corregir facilmente.

Desde luego si la planta no te lo tira para atras es que esta dentro de los margenes

Bueenas!!

Si, eso es lo que quiero decir. Por supuesto que si un estudio de mastering puede analizar las tramas, los BLER, etc... pues mejor que mejor, pero lo importante es estar dentro de los márgenes que permiten a las plantas duplicadoras trabajar, y eso se consigue ( según mi experiencia) facilmente grabando a por ejemplo 8x.

Mis análisis, como ya he dicho, se centraron en estudiar las posibles pérdidas de calidad en el sonido, y no tanto en los errores.

Me interesaba saber si aumentando la velocidad de grabación, los programas empezaban a hacer algún tipo de interpolaciones, perdiendo las datos menos "importantes" como sucede por ejemplo con la compresión a mp3.

El hilo se ha centrado en los errores, pero no ha tenido en cuenta los algorítmos que suceden en el programa de quemado, y que pudieran reducir la riqueza en matices del audio, al subir de velocidad, al utilizar uno u otro programa, etc.... Esto, era algo que había oído por diferentes fuentes, y me preocupó lo suficiente como para ponerme a estudiarlo. Y ahora llega este hilo, y empiezo a inquietarme por los errores... Estaréis contentos!!!

Ahora ya no puedo dormir, Joder!!

Por cierto, no recuerdo que Nero normalice nada, al menos no si no se lo pides... miraré a ver..

Normaliza si se lo pide, no se si hay alguna opcion por defecto

Alguien escribió:

Me interesaba saber si aumentando la velocidad de grabación, los programas empezaban a hacer algún tipo de interpolaciones, perdiendo las datos menos "importantes" como sucede por ejemplo con la compresión a mp3.

No entiendo muy bien a que te refieres con el mp3 y las interpolaciones. El mp3 se basa en la recodificacion por subbandas y lo que psicoacusticamente la oreja ya no es capaz de discernir. Las frecuencias mas graves enmascaran a las mas agudas por tanto si la banda de los 1000 Hz es de un nivel bastante superior a la de los 2000 Hz la banda de 2000 podra pasar desapercibida. Luego se pueden emplear menos bits en la codificacion de esta subbanda ya que aunque el ruido de cuantificacion aumente en esta banda, la banda de 1 KHz enmascarara este ruido de cuantificacion. El resultado es que vas ganando bits segun vas recodificando con menos bits las bandas enmascaradas. Esto es facilmente comprobable, date cuenta que lo que suele pasar cuando recodificas con menos bits las bandas superiores que son las mas sensibles al enmascaramiento, tarde o temprano pasaras el limite de la transparencia. El limite de la transparencia sucede cuando el ruido de la recuantificacion sobresale por encima del umbral de enmascaramiento creado por una banda. Al estar recuantificando fundamentalmente las frecuencias mas agudas, esto se traduce que si te pasas la cagas y comienza a sonar unos agudos totalmente artificiales y metalicos a lo Cher.
Los metodos de compresion mas transparentes de mpeg para el audio se basan fundamentalmente en dominios espectrales y no temporales, es decir el layer I esta provisto de unos filtros FIR en paralelo, los cuales hacen un filtrado por banda y se dedican a recuantificar la cadena de cada filtro. Este trabaja en el dominio temporal y suena como el culo. El layer II realiza la transformada de Fourier de la entrada y trabaja directamente con las señales en el dominio espectral, logicamente debera existir una etapa de analisis en el emisor y una de sintesis en el receptor para ser capaces de reconstruir la señal en el tiempo. El layer III o mp3 ya es lo mejor ya que junta lo mejor de cada uno de las familias, del layer I y del layer II. La interpolacion se suele hacer en los dominios temporales y el layer III trabaja sobre todo en el espectro, no comprendo muy bien a que te refieres con las interpolaciones del mp3

Alguien escribió:

El hilo se ha centrado en los errores, pero no ha tenido en cuenta los algorítmos que suceden en el programa de quemado, y que pudieran reducir la riqueza en matices del audio, al subir de velocidad, al utilizar uno u otro programa, etc.... Esto, era algo que había oído por diferentes fuentes, y me preocupó lo suficiente como para ponerme a estudiarlo. Y ahora llega este hilo, y empiezo a inquietarme por los errores... Estaréis contentos!!!

Pero a ver, estamos hablando de cosas diferentes, que ya me he perdido. Tu en un CD grabas bloques de datos, no grabas sonido tal cual como en un vinilo, es decir tu podrias hacer un estudio de como influye la velocidad de grabacion en un soporte cuya señal grabada sea una relacion directa con una forma de onda, pero un CD son solo bloques de hendiduras ( lands y pits ) no tiene ninguna relacion con la forma de onda. Es mas la codificacion de canal que emplea el CD es tal que intenta romper cualquier correlacion entre las hendiduras grabadas, el proceso de scramble ( aleatorizacion de los bits ) trata de desperdigar los bits a lo largo de los bloques con el fin de que un error de rafaga, por ejemplo un rallajo no afecta a un trozo de una cancion.
Por lo tanto el estudio de las velocidades de grabacion o del software utilizado no se puede contemplar directamente estudiando la perdida de riquezas del sonido, sino estudiando los errores por bloque, y encima ni siquiera con esto, porque muchos de estos son recuperables, y los que no son recuperables algunos si se pueden interpolar. El CD es de los soportes peores para grabar por todo sus funcionamiento intrinsenco. A su vez es de los mejores soportes contra errores que existen.
Puedes hacer un estudio de la riqueza del sonido tal cual en un magneto que grabe en analogico a diferentes velocidades, 15 ips o 30 ips seguro que hay diferencias, pero en un cd no se puede o al menos no directamente, ya que es tan complejo el sistema del CD que la señal que en el se almacena no tiene absolutamente ninguna correlacion directa con la forma de onda de la señal cuantificada. Por esta razon el estudio se hace en torno al BLER. Otra cosa distinta es que tu quieras comprobar la eficiencia de todo el sistema que conforma el maravilloso mundo del CD como soporte fisico y para ello realices diferentes tipos de pruebas, pero la planta duplicadora no se para en hacer estas cosas, y ellos solo analizan la trama de bloques y ni siquiera escuchan lo que esta grabado.

Algunos ya estan pasando del CD como soporte fisico de grabacion para entrega de master. Desde luego si me dejan elegir, un bias peak pro, un ddp y una conexion de adsl por ftp me es suficiente. Si no quieres comerte el coco con el tema del CD lo mejor es enviarlo por FTP, va perfecto, como anillo al dedo ( por no decir algo mas fuerte )

Holaa!!

Oí varias veces y por varias fuentes que al incrementar la velocidad, los programas empezaban a reducir datos y a interpolar. Incluso me dijeron que por aquí en Bilbao, había un freaky que era capaz de diferenciar un cd audio grabado con easy cd creator y Nero. Así que empecé a hacer pruebas, audiciones y gráficos para ver que había de verdad en eso.

Si le pides más velocidad de grabación al programa, parecía lógico pensar que por ejemplo, cogiera solo un tanto por ciento de los datos, e interpolara. No a nivel espectral, reduciendo tales frecuencias ( el ejemplo del mp3 no ha sido el mejor, desde luego... perdón) , sino aplicando logarítmos de interpolación en el dominio de amplitud/tiempo.

Me explico, aunque creo que ahora ya me estoy explicando mejor y Fourier ya me ha entendido.

Si tengo una muestra ( en el segundo 01:00:00, por ejemplo) con un valor de amplitud ( voltage ) "y", y tres samples ( muestras) más adelante tengo otra con el mismo valor "y", se puede interpolar y decir que las muestras intermedias también tienen una amplitud "y".
Pero en realidad puede que hayan oscilado, y una era "y+1" y la otra "y+2", con lo que en lugar del diente de sierra original, con la interpolación nos queda una linea recta.

Origen...............................interpolando

Muestra 1= y..............................y
Muestra 2= y+1...........................y
Muestra 3= y+2...........................y
muestra 4= y..............................y

Esta posibilidad me pareció muy peligrosa, así que intenté sacar algunas conclusiones. Mis análisis y mis preocupaciones iban en este sentido. Buscaba ver si se aplican procesos haciendo una especie de down-sample-rate. Algo parecido a reducir la frecuencia de muestreo, sospechando que tal vez al incrementar la velocidad el sistema de codificación empezaba a fallar, o a no ser tan riguroso, y empezaba a rellenar con "paja" suponiendo cosas raras....

Los datos que se graban en un cd, corrígeme porque no es precisamente mi campo, no dejan de ser los valores de las muestras, o sea, un valor de amplitud en un determinado momento o sample. El CD podrá ir por bloques o por códigos en los cuales, sinceramente me pierdo, pero no creo que se pueda decir que:

fourier escribió:

pero un CD son solo bloques de hendiduras ( lands y pits ) no tiene ninguna relacion con la forma de onda

fourier escribió:

a que es tan complejo el sistema del CD que la señal que en el se almacena no tiene absolutamente ninguna correlacion directa con la forma de onda de la señal cuantificada

Entiendo que el cd tiene sus códigos y sus formas, pero lo que registre, tras varios algorítmos, son los registros de amplitud de cada sample. Puede que los desparrame como dices:

fourier escribió:

el proceso de scramble ( aleatorizacion de los bits ) trata de desperdigar los bits a lo largo de los bloques con el fin de que un error de rafaga, por ejemplo un rallajo no afecta a un trozo de una cancion.

Puede usar no sé que tipo de métodos, ni en qué idioma, pero lo que quede registrado será música, o algo, que tras decodificarlo, volverá a ser música. Y mi mini-estudio, iba encaminado a ver si lo que mando entrar en un cd es lo mismo que recibo al reproducirlo después de tanto desparrame y despiporre de datos.

Insisto:

No pretendía ver los errores, ni los clicks....etc. Pretendía ver si al subir la velocidad, el programa empieza a no ser tan exhaustivo ni tan preciso, no por errores accidentales, sino por errores provocados por los programadores ante la necesidad de subir de velocidad y verse con poco ancho en el buss, o poco buffer o poco micro, y antes de que se quede colgado el sistema, hayan preferido sacrificar la calidad de audio reduciendo el número de muestras originales que se registren en el CD por suposiciones interpoláricas.

Hay que recordar que cuando se germinaron los programas de tostado, los ordenadores no eran lo que son ahora, y había que ahorrar recursos de donde fuera.

Así que si, entiendo que estamos hablando de dos cosas diferentes, y es que, no me había expresado tan bien como me lo había imaginado en mi cabeza

Un saludo!!!

Madre mia, lo de fourier no es ni medio normal.. menudo tocho..

en pocas palabras euridia, la informacion en un CD esta protegida por un codigo de correcion de errores matematico, este codigo permite mediante el añadido de informacion extra y la distribucion de esta en la trama, q aunq algun bloque no se pueda leer se extrapole con exactitud cuales eran los valores de este bloque.

Si son demasiados bloques consecutivos los q no se pueden leer, se produce un error no-corregible, osea q no se puede recuperar la informacion de estos bloques atraves de la extrapolacion de informacion en bloques cercanos. Este seria un error tipo CU (uncorrectable) y afectara a la integridad de los datos. osea q se podria llegar a oir. En cualkier caso, normalmente, el problema no esq haya errores CU, si no que haya demasiada tasa de errores C1 o C2 que con el tiempo y la degradacion fisica (abrasion)de la superficie del CD se puedan convertir en un CU.

De todas formas mientras no haya errores CU los errores C1 y C2 son totalmente corregibles con toda exactitud por el codigo de correccion de errores, asi q es imposible q nadie oiga una diferencia "sonora", al menos hasta q esos errores C1 y C2 no se conviertan en errores CU por la abrasion del disco, la diferencia de precision en la lectura de un transporte de CD a otro, o la propia quimica de la capa fotosensible de los CD-Rs

slds

Alguien escribió:

Si tengo una muestra ( en el segundo 01:00:00, por ejemplo) con un valor de amplitud ( voltage ) "y", y tres samples ( muestras) más adelante tengo otra con el mismo valor "y", se puede interpolar y decir que las muestras intermedias también tienen una amplitud "y".
Pero en realidad puede que hayan oscilado, y una era "y+1" y la otra "y+2", con lo que en lugar del diente de sierra original, con la interpolación nos queda una linea recta.

Origen...............................interpolando

Muestra 1= y..............................y
Muestra 2= y+1...........................y
Muestra 3= y+2...........................y
muestra 4= y..............................y

Esta posibilidad me pareció muy peligrosa, así que intenté sacar algunas conclusiones. Mis análisis y mis preocupaciones iban en este sentido.

este tipo de interpolacion no es exacta, osea no asegura q la informacion sea EXACTAMENTE la misma, eso solo lo hacen los lectores de CD cuando se encuentran con un error CU, donde el ECC (codigo de correccion de errores) ya no puede hacer nada. Digamos q esta es una situacion extrema y ninguna planta de duplicado te dejara llegar nisikiera cerca de un CU.

slds

Alguien escribió:

Pretendía ver si al subir la velocidad, el programa empieza a no ser tan exhaustivo ni tan preciso, no por errores accidentales, sino por errores provocados por los programadores ante la necesidad de subir de velocidad y verse con poco ancho en el buss, o poco buffer o poco micro, y antes de que se quede colgado el sistema, hayan preferido sacrificar la calidad de audio reduciendo el número de muestras originales que se registren en el CD por suposiciones interpoláricas.

Jesus! eso es paranoia y lo demas cuento... joder si estuviesemos tan expuestos a errores en la transferencia de informacion digital, los ordenadores habrian matado a mucha, pero mucha gente hace tiempo.

gracias a los ECCs y CRCs podemos estar trankilos...

slds

Entonces podemos respirar tranquilos???

He leido que el sistema de corrección de errores del CD es supremamente confiable (y que es una de las muchisimas ventajas de este soporte con respecto al vinilo).

Despues de leer tantos aportes interesantes yo concluiría que usando un software competente (incluso el Nero) y una grabadora y discos de calidad no hay porque temer a la perdida de datos o la aparición de errores.

Bueenas!!!

Chus escribió:

en pocas palabras euridia, la informacion en un CD esta protegida por un codigo de correcion de errores matematico, este codigo permite mediante el añadido de informacion extra y la distribucion de esta en la trama, q aunq algun bloque no se pueda leer se extrapole con exactitud cuales eran los valores de este bloque.

Entiendo lo que quieres decir, pero dos matices:

1) "Extrapolar con exactitud" es un contrasentido en sí mismo. Es como decir "redondear con exactitud". Puedes decir " con mucha exactitud", pero no "con exactitud". Y es aquí donde está todo el meollo del digital. Siempre se aproxima, pero nunca llega.

2) Entiendo lo que quieres decir, pero a mí no me preocupaban los errores accidentales, como rayaduras.

Chus escribió:

es imposible q nadie oiga una diferencia "sonora", al menos hasta q esos errores C1 y C2

Mi preocupación no eran los problemas sonoros en el CD en sí mismo, sino la "no transmisión" de todas y cada uno de las muestras del archivo de 16Bits al CD, cuando la velocidad aumenta.

Chus escribió:

este tipo de interpolacion no es exacta, osea no asegura q la informacion sea EXACTAMENTE la misma, eso solo lo hacen los lectores de CD cuando se encuentran con un error CU, donde el ECC (codigo de correccion de errores) ya no puede hacer nada. Digamos q esta es una situacion extrema y ninguna planta de duplicado te dejara llegar nisikiera cerca de un CU.

Eso mismo. Las interpolaciones no son exactas, o no tienen por que serlo, y a mí me preocupaban las que pudieran aparecer en los logarítmos del programa.

Chus escribió:

Jesus! eso es paranoia y lo demas cuento... joder si estuviesemos tan expuestos a errores en la transferencia de informacion digital, los ordenadores habrian matado a mucha, pero mucha gente hace tiempo.

Los fallos informáticos se suceden constantemente. ¿Se te ha olvidado la facilidad con la que se colgaban windows 95, 98,...?

Ten en cuenta que lo que yo digo no son ni fallos, ni en la transferencia.

Lo repito otra vez con otras palabras:

Mi preocupación, y por tanto mis intentos por saber que pasaba, es la diferencia de los tipos de algoritmos del programa de quemado en función de la velocidad. No los fallos. No los errores. Imagina que todos los procesos se hacen como deben hacerse, haces un análisis y te sale que los errores son cero. En estas condiciones, ¿como de excrupuloso ha sido el programa a medida que aumenta la velocidad? ¿Utiliza los mismos algorítmos? ?El proceso, es el mismo?

Puede que sea paranoia, la verdad es que visto desde fuera igual tienes razón, pero no tengo un solo cacharro en el estudio, previos, compresores, eqs,... al que no le haya hecho análisis y pruebas. De hecho, bastante gente me acerca al estudio sus bichos para que se los analice, gente de otros estudios, tiendas, autónomos, empresas de sonido... Y algunas veces, los resultados son sorprendentes. Yo pefiero ver las cosas por mí mismo, y no confiar demasiado en lo que te dicen.

Espero haberme dado a entender esta vez.

jhbenav escribió:

Despues de leer tantos aportes interesantes yo concluiría que usando un software competente (incluso el Nero) y una grabadora y discos de calidad no hay porque temer a la perdida de datos o la aparición de errores.

Vigilando la velocidad creo que no hay gran problema, incluso con Nero. Yo al menos no he detectado ninguna diferencia de sonido, y en cuanto a los errores, yo simpre le pido al programa una verificación de datos, y hago una escucha de las introducciones de los temas, y como he dicho, solo tuve un problema y estoy seguro de que fué debido al traqueteo de la carretera o a algún golpe que soltó algo por dentro.

Un saludo!

La verdad que no crei,que este tema se hubiese llegado a poner tan interesante. .

Creo q la he liado un poco por no usar correctamente el termino "extrapolacion"..

Alguien escribió:

Mi preocupación, y por tanto mis intentos por saber que pasaba, es la diferencia de los tipos de algoritmos del programa de quemado en función de la velocidad. No los fallos. No los errores. Imagina que todos los procesos se hacen como deben hacerse, haces un análisis y te sale que los errores son cero. En estas condiciones, ¿como de excrupuloso ha sido el programa a medida que aumenta la velocidad? ¿Utiliza los mismos algorítmos? ?El proceso, es el mismo?

Si esa es toda tu preocupacion (no se de donde habras sacado esa paranoia!¿?) entonces te aseguro q no hay ningun programa q reduzca o altere la informacion que le damos para que queme en un CD a menos q se lo digas (normalizar, añadir de-emphasis, 2 segundos entre pista y pista..etc). Lo q si q pasa esq al quemar esa informacion en el CD puede q no lo haga 100% perfecto por imprecisiones mecanicas del transporte y el sistema de seguimiento, sobre todo a velocidades altas. Algun bloque es muy posible q no se pueda leer una vez grabado el disco. Mientras solo sea algun bloque esporadico no pasara nada, ya q el algoritmo de ECC reconstruye perfectamente esos bloques apartir de datos en bloques mas o menos cercanos (ahi esta la magia matematica del Reed Solomon). Cuando el numero de bloques consecutivos es tan alto q hay algun bloque irrecuperable, entonces y solo entonces, los lectores de CD-audio "extrapolan" el valor de la informacion para q no se produzca un "click". Logicamente los CDs de datos no "extrapolan" nada, si no se puede leer algun bloque, informan de q no han podido acceder a tal bloque y carretera.

Alguien escribió:

y en cuanto a los errores, yo siempre le pido al programa una verificación de datos

esa verificacion de datos es despues del ECC asi q solo te informa de los errores CU, pero alguien q masteriza profesionalmente deberia preocuparse de la calidad de la trama antes del ECC y de no tener muchos C1 y C2 en el glass master, porq luego despues de planchados (suponiendo q lo acepten en la planta de duplicacion) esa tirada de CDs con muchos C2 va a degradarse con el tiempo y la abrasion, y tenderan a convertirse en CUs irrecuperables. Al cliente final q compra el CD d su artista favorito, no le gustara q a los pocos meses, y con unos pokitos arañazos, el CD empieze a saltar o hacer cliks por q todo ese ejercito de C2s se hayan convertido ahora en CUs.

De cualkier manera no estoy para nada familiarizado con el proceso de creacion de un glass master (no me dedico al mastering), no deberia, en teoria, importar demasiado la cantidad de C1s y C2s del premaster q entregemos, ellos deberian ripear la informacion y reconstruirla para no quemar C1s ni C2s q estuviesen en el premaster en el glass master.. asi q con no hubiese CUs deberia bastar.. pero si le dan la vuelta a premasters en CD por exceso de C2s me imagino q no pierdan tanto el tiempo.

Lo novedoso (al menos para mi) es el hecho de poder analizar el BLER del pre-master en casa, con hardware de consumo y soft libre.
Como ha comentado DW, todo esto esta muy bien para averiguar con q grabadora, a q velocidad, y con q CDs virgenes grabamos con menos tasa de errores, con un poco de prueba y error, ademas si hacemos tiradas pequeñas de CD-R podremos asegurarnos de q la longevidad y robustez de los CDs de la tirada sera decente.


slds

Chus escribió:

Si esa es toda tu preocupacion (no se de donde habras sacado esa paranoia!¿?) entonces te aseguro q no hay ningun programa q reduzca o altere la informacion que le damos para que queme en un CD a menos q se lo digas (normalizar, añadir de-emphasis, 2 segundos entre pista y pista..etc).

Alguien escribió:

Podría ser... pero me parece que aseguras muho y muy rapidamente.

El uso de la cpu del ordenador varía dependiendo de la velocidad de tostado. O así lo entiendo yo. Pero lo raro es que consume más recursos a velocidades bajas que a altas. Y concretamente a 1x, el consumo se dispara.

Entonces, ¿ por qué trabaja más la cpu a 1x que a 8x? ¿No debería ser al revés? ¿ No será que a 1x coge todas las muestras y las pasa una a una y a velocidades superiores no? O algo parecido, no sé... no soy informático, pero al menos a mí me parece raro y sospechoso.

Mira, fíjate abajo a la derecha, donde pone "uso de cpu".

Chus escribió:

pero alguien q masteriza profesionalmente deberia preocuparse de la calidad de la trama antes del ECC y de no tener muchos C1 y C2

Voy a hacer como Alfredo Forte ( por cierto Alfredo, un saludo y gracias por tus aportaciones, se ve que eres un crack!)

1) El CD de Ammy Winehouse " Back to black", limpio y sin rayaduras. Una superprodución.
2) Tom Waits, heartattack and wine. Consta en la lista de honor de Bob Katz.
3) Ben Harper, born to shine. También consta en la misma lista.