% TO-DO
% Compilar con LaTeX (y latex2html)
% Escribir las conclusiones
% Imprimir
% Proofread
% Publicar
\documentclass[a4paper,12pt,spanish,draft]{article}
% To handle acceents in output and input
\usepackage[spanish]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{eurosym}
% Basicos
\usepackage{tabularx}
% Programming
\usepackage{ifthen}
% Fonts
\usepackage{pslatex}
\usepackage[bookmarks=true]{hyperref}
\usepackage[a4paper, dvips]{geometry}
% To have HTML links
\usepackage{html}
% Useful things
\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}
\setlength{\parindent}{0ex}
% Shome shortcuts
\newcommand{\linkfootl}[3]{ \htmladdnormallinkfoot[#1]{#2}{#3} }
\newcommand{\linkfoot}[2]{ \htmladdnormallinkfoot{#1}{#2} }
\newcommand{\linkl}[3]{ \htmladdnormallink[#1]{#2}{#3} }
\newcommand{\link}[2]{ \htmladdnormallink{#1}{#2} }
% Page format
\geometry{
a4paper, top=0.5in, bottom=1.5in, left=0.75in, right=0.75in,
includemp = false}
\pagestyle{plain}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\title{Patas-arriba de la grabación de CD's}
%\author{Miguel Telleria}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
% Interparagraph distance
\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}
\setlength{\parindent}{0pt}
\maketitle
\abstract{Mi tostadora empieza a casca. A la hora de grabar con
\texttt{cdrecord} en modo TAO se atasca en el momento de la
fijación. Esto me ha forzado a explorar la grabación en modo SAO y
a base de leer estándares, mirar código y he recompilado mucha
información que quiero compartir con vosotros.
Este artículo (con un título prestado de antiguas épocas de los
8bits) pretende desmitificar algunos aspectos de la grabación de
CD's como son la multisesión, los tipos de pistas y el modo SAO.}
\tableofcontents
\section{Introducción}
Ya sea por algunos prejuicios como lo que pone en el
\linkfootl{CDWRITEhowto}{CD Write howto}{http://www.tldp.org/HOWTO/CD-Writing-HOWTO-3.html} o por
el hecho de que \emph{cdrdao} tuviera \linkfoot{problemas de
licencias en Debian}{http://people.debian.org/~joey/3.0r1}
durante algún tiempo, el caso es que muchos hemos estado utilizando la opción por
defecto de cdrecord de grabar siempre en modo TAO (Track At Once).
Ahora que mi grabadora está acatarrada (ya no puede grabar en
modo TAO) me he forzado a investigar un poco en detalle como funciona
el modo SAO (Session At Once),como generarlo con cdrecord y cdrdao y
las diferencias respecto al modo TAO.
\subsection{Licencia y advertencia}
Este artículo está bajo licencia \linkfoot{GNU FDL}{http://www.gnu.org/copyleft/fdl.html}.
Podéis bajaros el fichero fuente \LaTeX{}
\linkfoot{aquí}{http://www.mtelleria.org/articles/patas\_arriba\_grabacion\_cds.tex}.
Todo lo que pongo aquí es el resultado de observaciones de capturas,
de documentos e incluso de código fuente recogidas en un corto periodo de
tiempo. Entended que \textbf{yo no me considero una autoridad en la materia},
no trabajo en este dominio y no he programado \texttt{cdrecord} :).
Vamos que además de las erratas que seguro que habrá, \textbf{es muy posible
que haya comprendido alguna cosa de forma errónea}. Cualquier
comentario o corrección son bienvenidos.
\section{Un poco de teoría}
\subsection{Estructura de un CD (CD-ROM, CD-Audio, CD-extra...)}
Esto es un resumen de la sección 2 de
\linkfootl{cdfaq}{CD recordable FAQ}{http://www.cdrfaq.org}, así como
otras referencias de \cite{fuji, mmc, yellowbook}
\subsubsection{Sesiones, pistas y sectores}
Globalmente un CD se divide en \textbf{sesiones} que corresponden a diferentes momentos de
grabación. Internamente cada sesión se compone de:
\begin{description}
\item[Lead-in] Agrupa lo que se llama la \emph{pista 00} y contiene la
\textbf{tabla de contenidos (TOC)} donde se indican los contenidos
del area de programa y la existencia o no de una siguiente sesión
(ver \ref{teoria:multisesion}).
\item[Area de programa] Aquí está el contenido de usuario propiamente
dicho divido en \textbf{pistas} (tracks en inglés). Normalmente \footnote{La
especificación \cite{cdromxa} permite poner una única pista de
datos al principio seguida de pistas de audio, pero esta
funcionalidad ha sido y remplazada por la multisesión} tenemos o bien todo
pistas de audio cada una conteniendo una canción o bien una única
pista de datos conteniendo un sistema de ficheros iso9660 o UDF.
\item[Lead-out] Agrupa lo que se llama la \emph{pista AA} y no
contiene información en sí. Está pensada para que el laser tenga
una cierta tolerancia para apagarse y reposicionarse.
\end{description}
La unidad de direccionamiento en los CDs es el \textbf{sector} que
corresponde a 1/75avo de segundo de audio (98*6 muestras a 44100 Hz).
Existen 2 formas de numerar los sectores:
\begin{description}
\item[MSF] Nos basamos en la representación temporal MM:SS.FF donde
MM:SS son los minutos y segundos mientras que FF es el número de
sector \footnote{F viene del término \emph{frame} que en algunos
estándares (\cite{yellowbook}) es el nombre oficial de sector. Sin
embargo esto se presta a confusión con el término \emph{small frame}
que representa la mínima cantidad de audio extraíble (6 muestras).
Para evitar confusiones en el artículo se utiliza el término
sector.}. Así el último sector direccionable tiene la dirección
99:59.74.
\item[LBA] Los numeramos como en los discos duros de manera consecutiva.
\end{description}
La numeración LBA \textbf{empieza en el área de programa de la primera
sesión}. La numeración MSF empieza 2 segundos antes del area de
programa (ya se cuenta con un pre-gap). En ambos casos el Lead-In
tendrá siempre una dirección negativa.
Teniendo en cuenta que el audio está muestreado en stereo a 16 bits
(16 bit x 2 por muestra) esto hace que un sector corresponda a
\textbf{2352 bytes} de \textbf{información principal}. Para pistas que no
son de audio, 2352 bytes es el tamaño ``bruto'', dependiendo del tipo
de pista de datos se reservarán más o menos bytes para sincronismo y
protección de errores por lo que el tamaño ``neto'' de un sector de
datos será ligeramente inferior (normalmente 2048 bytes).
Además de la \emph{información principal} que representa el audio o
los datos del usuario, cada sector contiene \textbf{96 bytes} de \textbf{subcódigos
o canales P,Q,R,S,T,U,V,W} que llevan meta-información. Los 96
bytes están equitativamente repartidos en cada canal haciendo 12 bytes
cada uno. A lo largo del CD cada canal ocupa 500 Kb cada uno.
Los subcódigos tienen 2 funciones principales:
\begin{itemize}
\item En el \emph{lead-in} el canal Q guarda el TOC repitiéndolo a lo
largo de los 60 segundos que suele durar esta zona.
\item En el \emph{area de programa} en los CDs de audio llevan
metainformación como el valor del reloj, si se trata de un Gap y
hasta posibles extensiones como el texto de un karaoke (CD-TEXT) o
la imagen de la portada (CD-G).
\end{itemize}
A diferencia de la \emph{información principal} los subcódigos no
llevan ninguna protección contra errores, por lo que la única forma de
garantizar una buena protección es repetir su contenido continuamente.
Para completar, decir que antes de la primera sesión existe la zona
\emph{Power Calibratin Area (PCA)} de sólo lectura con metainformación
sobre el disco y otra zona, \emph{Program Management Area (PMA)}
ideada para almacenar ciertos datos temporales necesarios en la grabación.
\subsubsection{Tipos de pistas}
Centrándonos en las pistas existen varios tipos dependiendo de como
esten organizados los sectores:
\begin{tabularx}{\linewidth}{|l | p{0.125\linewidth} | X | p{0.125\linewidth} | } \hline
Tipo de pista & Datos / sector & comentario & parametro cdrecord \\ \hline
CD-DA & 2352 & CD de audio Todos los bytes de datos se dedican
integramente a muestras de audio sin protección contra
errores. Esta es el CD de música definido en el clásico \cite{redbook}
y \textbf{cuya vigencia se mantiene hasta ahora} \footnotemark
& \texttt{-audio} \\
\hline
CDROM 1 Mode 1 & 2048 & Se reservan 304 bytes para una protección de
errores adicional. Este es el CD-ROM de datos clásico definido en el \cite{yellowbook} \textbf{La gran mayoría de los
CD-ROMs son de este tipo} & \texttt{-data} \\ \hline
CDROM 1 Mode 2 & 2336 & También conocido como \emph{CDROM Mode 2
Formless}, una variante del CD-ROM clásico definida en el mismo \cite{yellowbook}
pensada para datos tolerantes a errores ocasionales (audio y video).
\textbf{Nunca cuajó}. Su funcionalidad fue reemplazada por los CD-ROM
XA. & \texttt{-mode2} \\ \hline
CDROM XA Mode 2 & 2048 (Form1)
2324 (Form2) & El standard \cite{cdromxa} redefine el formato de los
sectores del \emph{CDROM 1 Mode 2} para que puedan coexistir en una
misma pista sectores de datos fuertemente protegidos (Form1) con
sectores de datos de audio y vídeo debilmente protegidos (Form2).
Su aplicación más corriente es la grabación de datos y video en el \textbf{video CD (VCD)}
\cite{whitebook}.
También se ha difundido porque mucho software de grabación utiliza
este tipo de pistas por defecto a la hora de generar CD's multisesión
(\ref{teoria:xamulti}.
& \texttt{-xa} (Form1) \footnotemark
\texttt{-xa2} (Form2) \\ \hline
\end{tabularx}
% Notas de la tabla
\footnotetext{Salvo algunas tristes modas ``anti-piratería'' como el
\emph{bonus track} que no se abordan en este artículo}
\footnotetext{Existe la también opción
\texttt{-xa1} pero entonces la aplicación que genera la imagen tiene
que generar un 8 bytes más de metainformación por sector}
Además de esto están los CD-I \cite{greenbook} lejos de nuestro
interés ya que contienen incluso programas binarios compilados para un
procesador 68000 que tienen los reproductores Philips!!.
\subsubsection{Multisesión, fijación/finalización CDs abiertos/cerrados}
\label{teoria:multisesion}
Finalmente, después de 15 años de uso de CD's, en 1995 salió el
standard de la multisesión \cite{multi}. El principio es muy simple:
En el momento de grabar la sesión actual, si se quiere dejar el CD
abierto, \textbf{hay que incluir en el TOC de la sesión actual una
entrada especial \footnote{Tecnicamente modo 5 y valor de POINT
'BO'} que apunte a un sector de la sesión siguiente}.
Por lo tanto en CD's \emph{abiertos}, la última sesión tiene
dicha entrada y apunta a una dirección del disco que está sin quemar,
mientras que en los \textbf{cerrados} la última sesión no tiene esa
entrada o la tiene apuntando al valor FF:FF.FF.
Siguiendo con la retórica, la diferencia entre \emph{fijar} y
\emph{finalizar} una sesión es simplemente el incluir una entrada en
el TOC o no. Como el TOC se repite continuamente en todo el Lead-In,
\textbf{la cantidad de datos que se escribe en ambas operaciones es la
misma}.
El hecho de que haya entradas que apuntan a direcciones sin quemar
ofende a algunos lectores antiguos o puristas \footnote{De aquí la
leyenda de que convenga siempre finalizar un CD}, pero la mayoría de los
lectores modernos detectan la situación aceptan perfectamente los CD's
abiertos.
Dado que la grabación de CD's es un proceso de una única pasada, una
vez grabada la sesión no se puede cambiar el hecho de que esté abierto
o no, ya que ello implicaría el modificar la parte Lead-In de la
última sesión grabada.
Cuando se añade una sesión, aunque sea una sesión de 0 pistas de
contenido, se consumen al menos 2 minutos de espacio (4500
sectores, 18 MBytes en espacio de datos CD ROM 1 modo 1). Este
espacio corresponde a las zonas lead-in y lead-out que tienen que
tener al menos 1 minuto de duración cada una cuando están entre sesiones.
\subsubsection{Multisesión y pistas en CD-ROM XA Form1}
\label{teoria:xamulti}
Alguna gente, como por ejemplo el autor de \texttt{isofs.c} del kernel
linux, creen que de acuerdo a los standares, un CD-ROM multisesión debe tener las
pistas de datos en CD-ROM Mode 2 XA (en vez del clásico CD-ROM 1 Mode
1).
Sea como fuere es un hecho que diferentes programas de grabación
generan por defecto los 2 tipos de pista por lo que ambos están
perfectamente admitidos.
\subsubsection{Combinaciones posibles}
Con la llegada de la multisesión ya no se hace otra cosa que:
\begin{itemize}
\item CD con una primera sesión compuesta únicamente por pistas de
audio (CD-DA) y una o varias posibles sesiones con una única pista de datos
CD-ROM 1 cada una. Cuando existen estas sesiones de datos añadidas, al CD se
le denomina \emph{CD extra}
\item CD con una o varias sesiónes de datos cada una con una única pista CD-ROM 1.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Grabadoras}
Ahora que sabemos como se organizan los datos en el CD, es importante
ver como se acceden a ellos con los lectores y grabadores.
\subsubsection{Estandard MMC}
En general las grabadoras siguen unos comandos estandars que se llaman
\textbf{MMC (MultiMedia Command Set)}. Pertenecen a la familia de
comandos SCSI pero eso no evita que además de en conexiones físicas
SCSI se puedan utilizar en IDE/ATA (mediante el sistema ATAPI), USB o
ieee1394.
Al igual que todo lo de SCSI, las normas las lleva el comité
\link{T10}{http://www.t10.org}. Los estandares de MMC son de pago, pero
sin embargo las últimas versiones de los borradores
\linkfootl{mmcdownload}{se pueden descargar gratuitamente}
{http://www.t10.org/drafts.htm}.
Os recomiendo el draft del MMC4 que aunque no es la última norma
(ahora se está discutiendo el MMC5) está más que completa para lo que
necesitamos saber.
Otra fuente de conocimiento son las opciones \texttt{-V} y
\texttt{-VV} de \texttt{cdrecord} que muestran en pantalla los
comandos mandados y datos recibidos. Con \texttt{-VV} también vemos
los datos que nosotros enviamos a la grabadora.
\subsubsection{Modo de grabación TAO}
TAO (Track At Once) es la forma más comun de grabar CDs de datos y de
audio y es la que utilizan casi todos los programas por defecto.
Se le manda al grabador las pistas del área de programa \textbf{una
por una} y es el propio grabador el que lleva la cuenta de cada
pista y genera el TOC cuando se le pide al final.
Esta es la forma más sencilla de grabar un CD ya que el programa de
grabación no necesita saber de antemano la longitud del área de
programa.
Sin embargo tiene 2 problemas:
\begin{itemize}
\item Se generan siempre unos silencios entre pistas de duración no
menor de 2 segundos.
\item Después de grabar las pistas, el laser se tiene que reposicionar
al principio para grabar el lead-in. Esta es la parte más delicada
de la operación y es lo primero que falla cuando la grabadora
empieza a cascar :).
\end{itemize}
Para entender bien en que consiste merece la pena explorar la secuencia de
comandos MMC que cdrecord envía a la grabadora así como las respuestas
de esta. A continuación listo los comandos importantes que he
encontrado en mis observaciones (entre paréntesis los códigos de cada
comando según \cite{mmc4}):\footnote{información obtenida de la \emph{verbosidad} de
\texttt{cdrecord} y contrastada y contrastada más o menos con el código fuente
(\texttt{cdrecord.c}, \texttt{drv\_mmc.c} y \texttt{scsi\_cdr.c}).}:
\begin{enumerate}
\item \emph{MODE\_SELECT\_10(55)}: Se indica modo TAO, el tipo de pistas,
tiempo de gap, si es multisesión (\cite{mmc4}, pag 470)...
\item Para cada pista:
\begin{enumerate}
\item \emph{MODE\_SELECT\_10(55)} para poner el ISRC y otros parámetros de
la pista.
\item \emph{READ\_TRACK\_INFO(52)} preguntando por la ``pista
invisible'' (número FF). De aquí se obtiene el sector de comienzo
de la siguiente pista en el área de programa. Esta dirección de
comienzo ya tiene en cuenta el espacio del lead-in y los gaps
entre pistas.
\item Una serie de \emph{WRITE\_10(2A)} donde se manda la
información en bloques de 64 Kb. En cada comando se especifica el
sector de escritura y la cantidad de sectores.
\item De vez en cuando un \emph{READ\_BUFFER\_CAPACITY(5C)} para
monotorizar el estado del buffer.
\item Un \emph{SYNCHRONISE\_CACHE(35)} para asegurarse que todos los datos
se han grabado.
\end{enumerate}
\item \emph{CLOSE\_TRACK/SESSION (5B)}: Se le pide a la grabadora que
haga la finalización ella solita. El único parámetro que se le pasa
en el CDB es \emph{close functin} a 2 (sesión actual).
Supongo que el grabador habrá ido anotando el comienzo de cada pista
cada vez que se le lanza un \emph{SYNCHRONISE\_CACHE} y que con esa
información, junto con los parámetros enviados en el primer
\emph{MODE\_SELECT} construye el TOC.
\end{enumerate}
\subsubsection{Modo de grabación SAO}
\textbf{En SAO (Session At Once)} se empieza dando al grabador una
especie de TOC denominado \textbf{CUE sheet} que indica exactamente
donde van a comenzar las pistas. Con esta información el grabador
construirá el Lead-In y el TOC.
A continuación se envían todas las pistas del area de programa de una
sola vez. Y al hacer el \emph{flush} el grabador grabará el leadout.
Por lo tanto el disco se graba de continuo sin silencios (aunque nada
nos impide fabricarlos) y el laser no se tiene que apagar ni
reposicionar.
Este método es el único que garantiza la obtención de 2 CD's idénticos
en cuanto a la posicion de sus pistas \footnote{Lo que garantiza que
el identificativo de CDDB también sea el mismo} y por lo tanto es el
único que se utiliza en producciones industriales.
De nuevo podemos capturar los comandos MMC que se envían.
\begin{enumerate}
\item \emph{MODE\_SELECT\_10(55)}: Se indica modo SAO, el tipo de pistas,
y si es o no multisesión \cite{mmc4}, pag 470)
\item \emph{SEND\_CUE\_SHEET(5D)}: Se le indica al grabador los
momentos de comienzo de cada pista.
\item \emph{MODE\_SELECT\_10(55)} para poner el ISRC y otros
parámetros \textbf{que se aplicarán a todas las pistas}.
\item \emph{READ\_TRACK\_INFO(52)} preguntando por la ``pista
invisible'' (número FF). De aquí se obtiene el sector de comienzo
del área de programa (justo después del lead-in).
\item Una serie de \emph{WRITE\_10(2A)} donde se manda la
información en bloques de 64 Kb \textbf{a lo largo de toda la sesión}
\item De vez en cuando un \emph{READ\_BUFFER\_CAPACITY(5C)} para
monotorizar el estado del buffer.
\item Un \emph{SYNCHRONISE\_CACHE(35)} para asegurarse que todos los datos
se han grabado.
\end{enumerate}
Y no hay nada más!!. Supongo que el grabador generará el lead-out
automáticamente con el comando \emph{SYNCHRONISE\_CACHE}.
\subsubsection{¿Qué es eso del DAO (Disk At Once)?}
Académicamente hablando DAO significa grabar la sesión de manera
continua \textbf{sin dejar la sesión abierta} mientras que con SAO el
tema de cerrar el disco o no es indiferente.
Cuando se introdujo la multisesión (en 1995 \cite{multi}), la
industria del CD ya llevaba un largo camino y los únicos términos
acuñados TAO y DAO se referían a si se grababan todas las pistas
juntas o no.
Al poco la gente se dio cuenta de que el término DAO se prestaba a
confusión ya que el hecho de grabar una sesión con pistas de audio de
una sola vez, no significaba necesariamente que el CD estuviera
terminado (ej los \emph{CD extra}.
Para evitar malentendidos se empezó a utilizar el termino SAO (Session
At Once) como contrasentido de TAO y el termino DAO se quedó para
escificar CD's SAO cerrados (que suele ser el caso de los CDs
industriales que eran el principal objetivo del sistema).
En este artículo he tomado la decisión de utilizar siempre el término
SAO ya que todos los ejemplos conciernen CDs abiertos.
A notar también que se pueden hacer perfectamente CD's TAO cerrados
pero que al no estar las pistas seguidas no se les puede llamar
DAO's. Que yo sepa no existe ningún termino para el hecho de que una
grabación TAO esté cerrada o no.
\subsubsection{Otros modos de escritura}
Para completar, decir que existen otros 2 modos de escritura:
\begin{description}
\item[Raw] Este es el método manual en el que hay que el grabador no
nos ayuda nada. El lead-in, lead-out e incluso los subcódigos son
generados por la aplicación y mandados al grabador.
\item[Paquete] El modo paquete está pensado para poder escribir un CD
incrementalmente en pequeños trozos de grabación pero sin generar
la pérdida de 2 minutos cada vez que añade algo nuevo como pasa con
la multisesión.
En este modo se suele utilizar con el sistema de ficheros UDF
optimizado para poder añadir elementos sin consumir mucho espacio
extra.
\end{description}
Todos estos temas quedan fuera del alcance de este artículo.
\subsubsection{Combinaciones posibles}
El comando \texttt{cdrecord -prcap} mostrará las capacidades que la
grabadora anuncia tener, como tipos de CD's y DVD's que admite, modos
de grabación, tipos de pista, velocidades...
Sin embargo esto no significa que cualquier combinación sea posible.
Las mayores limitaciones suelen venir con el \emph{modo SAO}. Hay
firmwares que con la idea inicial de SAO=DAO se niegan ha grabar
sesiones abiertas en este modo. También es un caso frecuente el que no
admitan grabar pistas CD-ROM XA en modo SAO.
Cuando se intenta una combinación imposible, el grabador da una
respuesta de error con una \emph{Sense Key} 0x5 y un \emph{Sense Code}
de 0x24, 0x25 o 0x26.
\begin{verbatim}
cdrecord: Success. send_cue_sheet: scsi sendcmd: no error
CDB: 5D 00 00 00 00 00 00 00 20 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 26 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 32
\end{verbatim}
Normalmente estas situaciones se detectan antes de que se haya escrito ningún dato (comando
\emph{WRITE\_10(2A}) por lo que el CD-R no suele ser afectado.
\subsection{Imagenes ISO9660}
\label{teoria:iso9660}
Hasta ahora hemos hablado de la estructura de sesiones y pistas en los
CD's, y como se graban los datos. Sin embargo no hemos hablado de la
estructura de dichos datos.
Los datos que pongamos en principio es cosa nuestra, nada nos impide
poner un sistema de ficheros ext2 o incluso fat, pero si queremos
hacer las cosas normales utilizaremos el sistema iso9660.
Al ser de sólo lectura, la estructura interna de iso9660 es muy
sencilla. Los ficheros se ponen uno tras otro alineados con el
comienzo y fin de los bloques típicamente de 2048 bytes (lo mismo que
el tamaño del sector de la pista).
Al principio \footnote{exactamente en el 16avo sector de 2048 bytes}
del sistema de ficheros existe el \textbf{PVD: Primary Volume
Descriptor} con información global del sistema de archivos: tamaño y
número de bloques, etiqueta, presencia o no de extensiones Joliet,
RockRidge...
\textbf{Nota:} A partir de aquí utilizaré el término sector para
referirme a bloque de datos.
Luego llega la \textbf{path list} con la lista de directorios y
ficheros. Para cada fichero se indica el número de sector en el que
está.
Y poco más que decir salvo dos cosas.
\subsubsection{ISO9660 y multisesión}
Los punteros de número de sector que aparecen en el \emph{path list}
se interpretan siempre como valores absolutos dentro del CD.
Por lo tanto si se quiere crear un segunda sesión de datos, \textbf{hay que
conocer el número de sector de comienzo de la pista de datos} antés de
construir la imagen .ISO. Normalmente este valor se le pregunta al
propio grabador con el disco dentro mediante el comando MMC
\emph{READ\_TRACK\_INFO(52)} especificando \texttt{FF} como número de
track. Por eso suele ser necesario tener el CD dentro del lector
justo antes de comenzar a generar una imagen ISO de continuación
\footnote{Aunque conociendo el sistema de grabación se podría
este offset se podría adivinar, al ser el grabador el que va a
decidirlo de todas formas en las grabaciones TAO y SAO, es mejor
preguntarle a él}.
Un segundo factor es la \textbf{importación de ficheros de sesiones
anteriores}. En un CD-ROM multisesión \textbf{sólo valdrá el path\_list
de la última sesión}. Por lo tanto para ver ficheros de sesiones
anteriores, \textbf{es necesario añadir sus entradas de path\_list a la
\emph{path\_list} de la imagen ISO que queremos generar}. Esta acción
se denomina mezclar \emph{merge en ingles}. Dado que la numeración de
sectores es absoluta basta con copiar solamente esas entradas sin
hacer ningún ajuste más. Esto se puede hacer también de manera
selectiva permitiendo que ciertos ficheros aparezcan y otros no.
\subsubsection{CDROM's de arranque}
El estandar \emph{El Torito} \cite{torito} describe como crear CD's de
arranque.
Consiste en incluir un fichero con una imagen de arranque \footnote{el documento da
la posibilidad de poner una por defecto y otras que el usuario pueda
seleccionar después pero aquí vamos a describir el sistema típico} y
otro fichero llamado el \textbf{boot catalogue} que diga donde se
encuentra la imagen y las opciones que se aplican a ella.
Estos ficheros se indican en una zona particular del fichero iso9660.
La imagen se puede ejecutar de 3 formas diferentes:
\begin{itemize}
\item Con una \textbf{emulación de disquete}. La BIOS considerará la
imagen como el primer disquete del sistema (\texttt{/dev/fd0} o
\texttt{A:} en Hasefroch) y desplazará el disquete existente a la
segunda posición (\texttt{/dev/fd1}, \texttt{B:}) eliminando
cualquier acceso al segundo lector.
La \textbf{imagen ha de tener un tamaño estandar 1.2M, 1.44M o 2.88M} y para
acceder al CD (fuera de la propia imagen) se tienen que usar los
comandos MMC-ATAPI de siempre.
Este el sistema que se utiliza con BIOS antiguas porque es el que
menos problemas daba. Para construir esta imagen se suele utilizar
\link{Syslinux}{http://syslinux.zytor.com/}.
\item Con una \textbf{emulación de disco duro}. Este sistema no se
utiliza nunca ya que oculta el disco duro de verdad.
\item \textbf{Sin emulación}. La imagen se carga directamente y las
asignaciones de la BIOS no cambian para nada. Este es el sistema
que se utiliza más normalmente y para construir la imagen se utiliza
\link{Isolinux}{http://syslinux.zytor.com/iso.php}.
\end{itemize}
Tened en cuenta que para que esto funcione la BIOS ha de colaborar, lo
cual no siempre es el caso.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Y ahora un poco de practica}
\label{practica}
\subsection{Opciones por defecto de cdrecord y mkisofs}
Para evitarme el tener que teclear siempre las mismas opciones (que
es lo que hace pesado al cdrecord) yo he hecho 2 cosas:
\begin{enumerate}
\item Al menos en Debian, en el fichero \texttt{/etc/default/cdrecord}
se pueden especificar el dispositivo (\texttt{ATA:1,0,0} para kernels 2.6 con
\texttt{ide-cd} y \texttt{0,n,0} para 2.4 con \texttt{ide-scsi}),
la velocidad de grabación y el tamaño de la FIFO.
\item Además me he creado un simple script bash en
\texttt{/usr/local/bin/micdrecord} con el resto de opciones que
utilizo en la mayoría de los casos. El script se reduce a:
\begin{verbatim}
#!/bin/bash
/usr/bin/cdrecord -v -eject -multi $*
# $ ignore this line (used for auctex faulty math mode detection)
\end{verbatim}
\end{enumerate}
La opción \texttt{-v} hace que se muestre la cuenta de los bytes
escritos \texttt{-multi} hace que la sesión se quede siempre abierta
para poder añadir más cosas en el futuro, \texttt{-eject} hace que el
CD se expulse al terminar la grabación.
Algo parecido he hecho para mkisofs
(\texttt{/usr/local/bin/mimkisofs}):
\begin{verbatim}
#!/bin/sh
/usr/bin/mkisofs -J -R -r -v $*
#$ ignore this line (used for auctex faulty math mode detection)
\end{verbatim}
Las opciones \texttt{-R} y \texttt{-J} activan las extensiones
RockRidge y Joliet, \texttt{-r} hace que los permisos de los ficheros también se
incluyan en la imagen y \texttt{-v} hace que vaya mostrando el proceso.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Obteniendo información del grabador y del CD}
Para ver las \textbf{capacidades del lector}, \texttt{cdrecord -prcap} lista
lo que puede y no puede hacer el lector. No se necesita tener un CD
introducido.
En cuanto al \textbf{contenido del CD} no he encontrado ningún comando
que nos dé de una tirada toda la información del TOC comodamente puesta. Sin embargo
los siguientes comandos nos dan toda la información que necesitamos.
\begin{tabularx}{\textwidth}{|>{\texttt{}}l | X | } \hline
cdrecord -toc &
Muestra \textbf{el comienzo de cada pista} saltándose los
lead-out y lead-in de entre las sesiones. Sin embargo no nos dice
nada en cuanto a sus duraciónes.
Podemos identificar también el tipo de pista:
\begin{description}
\item[cd-da] control:0 (modo 1 o -1 en función de si es la última
sesión o no).
\item[CD-ROM 1 Mode 1] control: 4 Mode 1
\item[CD-ROM XA Mode 2] control: 4 Mode 2
\end{description}
Curiosamente este comando \textbf{no nos dice si el CD esta abierto o no}. He
probado con 2 CD's del mismo contenido, uno abierto y otro no y no he
apreciado ninguna diferencia.\\ \hline
cdrecord -msinfo &
Cuando el CD está abierto (se grabó con la opción
\texttt{-multi}) nos da 2 números: primero el \textbf{sector donde empieza el
área de programa de la última sesión actual} del CD y segundo el
sector dondé empezará el área de programa de la sesión futura.
Estos 2 numeros hay que pasárselos con la opcion \texttt{-C} a
\texttt{mkisofs} para que genere el offset de sus punteros y pueda
encontrar la lista de ficheros existentes para importarlos a la sesión
actual. \\
isoinfo -d -T -i /dev/cdrom & (Solo para pistas de datos)
\texttt{sector} es el numero de comienzo de la sesión obtenido con
\texttt{cdrecord -toc}.
Este comando nos lee el \emph{PVD} (Sect \ref{teoria:iso9660} donde está
el tamaño del bloque de la imagen ISO así como el número de
bloques/sectores que la componen. Podemos asumir que el resto de
sectores no llevan información de usuario y contienen los lead-out y
lead-in de cada sector. \\ \hline
\end{tabularx}
Por último también hay varias formas de explorar el \textbf{contenido de
una imagen ISO9660}. Además de montarla en loopback (lo cual
requiere un proceso especial si es una segunda multisesión
\ref{practica:extraccion}), podemos averiguar varias cosas de un fichero
iso con el comando \texttt{isoinfo}. En todos los casos \texttt{-N
} es el sector de offset especificado a la hora de crear la
imagen (el segundo número del output de \texttt{cdrecord -msinfo}.
Para la imagen de la primera sesión no hace falta ponerlo.
\begin{tabularx}{\textwidth}{|>{\ttfamily}l | X | } \hline
isoinfo -d -N -i & Nos lee el encabezado
\emph{PVD}. Si el valor de \texttt{sector} es incorrecto obtendremos
un error en la última línea o una información incorrecta respecto a
las extensiones RockRidge. \\ \hline
isoinfo -l -J -R -N -d -i &
Con esto obtenemos un listado ls-lR de todos los ficheros de la
imagen incluídos los importados de la sesión anterior. En cada línea
se nos especifica en que sector se coloca cada fichero.\\ \hline
\end{tabularx}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Grabación de un CD multisesión con \texttt{cdrecord}}
\label{practica:cdmulti}
Tenemos 3 directorios: \texttt{session1}, \texttt{session2} y
\texttt{session3}. Haremos el CD de manera incremental con cada uno
de ellos.
Para hacerlo más ``especial'' vamos a grabar la primera sesión en modo
SAO y con un tipo de pista CD-ROM 1 Mode 1 para ver si la grabadora
nos deja.
\begin{enumerate}
\item \textbf{Creamos la imagen iso inicial} en el fichero \texttt{session1.iso},
incluímos Joliet (\texttt{-J}), Rock Ridge(\texttt{-R}) y pasamos
los permisos(\texttt{-r}).
Al volumen le llamamos ``session1'' (\texttt{-V}):
\begin{verbatim}
mkisofs -R -r -J -v -V session1 -o session1.iso session1
\end{verbatim}
\item \textbf{Gravamos la primera imagen en modo SAO dejando abierta la
multisesión}
Para hacer esto con \texttt{cdrecord} hay que tener en cuenta 2 cosas:
\begin{itemize}
\item Cuando se especifica el modo SAO (\texttt{-sao} hay que darle a \texttt{cdrecord} el
numero de bytes que hay que grabar de antemano de forma que pueda
generar la CUE-sheet. Si la imagen es iso9660 (o también para pistas
de audio en .wav) lo más práctico es utilizar es utilizar
simplemente la opción \texttt{-useinfo} \footnote{La página man
recomienda la forma general utilizar la opcion ts= con
lo que se pondría el número de bytes del fichero}.
\item En multisesión (\texttt{-multi}, quizás por los rumores de \ref{teoria:xamulti},
\texttt{cdrecord} cambia el tipo de pista de datos por defecto a CD-ROM XA
Mode 2 Form 1. Esto en sí no es grave en modo TAO, pero sin embargo
en modo SAO muchas grabadoras no aceptan este tipo de pista.
Para resolver el problema se le fuerza a \texttt{cdrecord} a
utilizar el tipo de pista normal (CD-ROM 1 Modo 1) con la opción
\texttt{-data}.
\end{itemize}
Con todo lo dicho, el comando queda (quitando los parametros guardados
en \texttt{/etc/default/cdrecord}:
\begin{verbatim}
cdrecord -v -eject -multi -sao -useinfo -data session1.iso
\end{verbatim}
\item Para crear la siguiente imagen ISO necesitamos conocer el
principio y final de la última sesión presente en el CD:
\begin{verbatim}
cdrecord -msinfo
\end{verbatim}
Si el CD no esta abierto (no pusimos \texttt{-multi} antes),
entonces puede que a cdrecord le de un \emph{media loading error} y
pida que se meta otro CD. Evidentemente basta con dar a Ctrl-C.
En mi caso la última línea me ha dado los valores \texttt{0, 21007}
\item Creamos la segunda imagen ISO especificando el offset (\texttt{-C} y
haciendo el \emph{merge} (\texttt{-M} con los ficheros de la sesión
anterior.
\begin{verbatim}
mkisofs -v -J -R -r -V ``session2'' -o session2.iso -C 0,21007 -M /dev/cdrom session2
\end{verbatim}
Nota: También podríamos haber dado \texttt{-M session1.iso} en vez de
tener que mirar en el CD anterior. Y podríamos incluso no hacer
ninguna mezcla con lo que los ficheros de la primera sesión quedarían
tapados por la segunda.
\item Añadimos la segunda imagen al CD.
Esta vez lo he tenido que hacer en modo TAO \footnote{la grabadora
no se ha quejó en modo SAO pero mi CD quedó iligible}. Fuerzo de
nuevo el modo de pista CD-ROM 1 Mode 1 para \textbf{mantener el mismo tipo
de pista de datos en todas las sesiones CD}.
El comando queda:
\begin{verbatim}
cdrecord -v -eject -multi -data session2.iso
\end{verbatim}
\item \textbf{Volvemos a preguntar la información de multisesión} al grabador
\begin{verbatim}
cdrecord -msinfo
\end{verbatim}
Esta vez yo obtengo \texttt{21007,26511}
\item \textbf{Generamos la tercera imagen ISO} de una forma similar a la
segunda.
\begin{verbatim}
mkisofs -v -J -R -r -V ``session3'' -o session3.iso -C 21007,26511 -M /dev/cdrom session3
\end{verbatim}
Esta vez \textbf{no podríamos especificar \texttt{-M session2.iso}} ya
que los ficheros no se encuentran físicamente en los sectores que
tiene el índice. Para esto tendríamos que utilizar un fichero ISO
conteniendo una imagen exacta del CD (ver \ref{practica:extraccion}).
\item \textbf{Sólo nos queda añadir el tercer fichero iso} (y dejamos el CD
abierto siempre).
\begin{verbatim}
cdrecord -v -eject -multi -data session2.iso
\end{verbatim}
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Grabación de un cd extra}
Un CD extra es un CD cuya primera sesión contiene exclusivamente
pistas de audio y las siguientes pistas de datos. En nuestro caso
tenemis 3 canciones: \texttt{pista1.wav}, \texttt{pista2.wav}, \texttt{pista3.wav} y 2 pistas de
datos \texttt{session1} y \texttt{session2}.
El proceso es similar al anterior.
\begin{enumerate}
\item Grabamos las pistas de audio en modo SAO dejando el CD abierto.
\begin{verbatim}
cdrecord -v -eject -multi -sao -useinfo pista1.wav pista2.wav pista3.wav
\end{verbatim}
\item Obtenemos la información de multisesión:
\begin{verbatim}
cdrecord -msinfo
\end{verbatim}
En mi caso me ha salido: 0,63352.
\item Generamos la primera imagen ISO:
\begin{verbatim}
mkisofs -v -J -R -r -V session1 -o session1.iso -C 0,63352 session1
\end{verbatim}
El caso del CD extra es el típico en el que no se hace el \emph{merge}
con la sesión anterior, por lo que se omite el parámetro \texttt{-M}.
\item Grabamos la primera imagen ISO al CD (de nuevo la grabadora no
me deja hacer SAO)
\begin{verbatim}
cdrecord -v -eject -multi session1.iso
\end{verbatim}
Como no he puesto la opción \texttt{-data} la pista se grabará como
\emph{CD-ROM XA Mode 2 Form 1}. Pues muy bien.
\item Y ahora ya sabéis el resto, no?
\begin{verbatim}
cdrecord -msinfo
mkisofs -v -J -R -r -V session2 -o session2.iso -C 63352,79861 -M /dev/cdrom session2
cdrecord -v -eject -multi session2.iso
\end{verbatim}
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Extracción y montaje en loopback de imágenes ISO multisesión}
\label{practica:extraccion}
Todo lo que entra ha de poder salir. Si por alguna razón queremos
copiar un CD multisesión sin regenerar las sesiones o queremos
recuperar algún fichero que quedó tapado tiene que haber algún modo de
conseguirlo. \textbf{Mientras sepamos lo que estamos haciendo} podremos conseguir lo que
queramos.
Tenemos el CD multisesión de la práctica en \ref{practica:cdmulti}.
Queremos obtener las sesiones en el disco duro y montarlas en
loopback.
En algunos casos quizás se pudiera obtener todo de una tirada con
\texttt{readcd /dev/cdrom} o un \texttt{dd} con una amplitud lo
suficientemente grande para abarcar todas las sesiones.
El problema sin embargo es que las zonas de leadout-leadin entre
sesiones no suelen tener los códigos de protección contra error
calculados con lo que dan errores de lectura tanto a \texttt{readcd}
como al driver del cdrom de linux que es utilizado por \texttt{dd}.
Por lo tanto tenemos que extraer cada sesión separadamente.
El proceso es el siguiente.
\begin{enumerate}
\item Hacemos un \texttt{cdrecord -toc} que nos da lo siguiente.
\begin{verbatim}
first: 1 last 4
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1
track: 2 lba: 21007 ( 84028) 04:42:07 adr: 1 control: 4 mode: 1
track: 3 lba: 33498 ( 133992) 07:28:48 adr: 1 control: 4 mode: 1
track:lout lba: 51873 ( 224052) 12:28:63 adr: 1 control: 4 mode: -1
\end{verbatim}
Con esto vemos que las 3 sesiones empiezan en los sectores \texttt{0},
\texttt{21007}, \texttt{33498}
\item Como sabemos que son pistas iso, utilizamos \texttt{isoinfo}
para averiguar su tamaño.
\begin{verbatim}
isoinfo -d -T 0 -i /dev/cdrom -> Volume size is: 9607
isoinfo -d -T 21007 -i /dev/cdrom -> Volume size is: 5589
isoinfo -d -T 33498 -i /dev/cdrom -> Volume size is: 11473
\end{verbatim}
Asegurándonos siempre de que el tamaño del bloque es de 2048 bytes.
Ya tenemos todos los datos y nos podemos hacer la tabla siguiente.
\begin{tabular}{|l|r|r|r|} \hline
Pista & Comienzo & Tamaño & Sector siguiente \\ \hline
1 & 0 & 9607 & 9607 \\ \hline
2 & 21007 & 5589 & 26596 \\ \hline
3 & 33498 & 11473 & 44971 \\ \hline
\end{tabular}
Ya tenemos todos los datos
\end{enumerate}
\item Extraemos las pistas.
Se pueden hacer tanto con \texttt{dd} como con \texttt{readcd}
\begin{tabularx}{\textwidth}{|X|X|}
\textbf{Usando dd} & \textbf{Usando readcd} \\ \hline
\texttt{dd bs=2048 if=/dev/cdrom of=session1.iso count=9607} &
\texttt{readcd sectors=0-9607 -f=session1.iso} \\ \hline
\texttt{dd bs=2048 if=/dev/cdrom of=session2.iso count=5589 skip=21007}
& \texttt{readcd sectors=21007-26596 -f=session2.iso} \\ \hline
\texttt{dd bs=2048 if=/dev/cdrom of=session3.iso count=11473
skip=33498} & \texttt{readcd sectors=33498-44971 -f=session3.iso} \\ \hline
\end{tabularx}
Con esto ya tendríamos suficiente para volver a crear un nuevo CD a partir de
las imágenes. Es importante que cada sesión se graba en el mismo modo
SAO/TAO que en el CD original ya que si no TAO produce 2 sectores más
de lead-out lo que hace que los punteros de ficheros de las sesion
siguientes no correspondan a la realidad.
En el caso del ejemplo tendríamos que hacer:
\begin{enumerate}
\item \texttt{cdrecord -v -eject -multi -sao -useinfo -data
session1.iso}
\item \texttt{cdrecord -v -eject -multi -data session2.iso}
\item \texttt{cdrecord -v -eject -multi -data session3.iso}
\end{enumerate}
\item Para montar las imágenes en loopback tenemos que crear primero un
fichero que represente al CD donde \textbf{cada sesión esté ubicada
en la misma posición que el CD}. El espacio intermedio lo
rellenaremos de ceros.
A partir de las tablas que nos hemos construído, calculamos los
espacios intermedios.
\begin{tabular}{|l|r|r|r|} \hline
Espacio & Comienzo & Final & Tamaño \\ \hline
1-2 9607 0 & 21006 & 11400 \\ \hline
2 & 26596 & 33497 & 6902 \\ \hline
\end{tabular}
Generamos los ficheros de valor a partir de \texttt{/dev/zero}.
\begin{verbatim}
dd if=/dev/zero of=inter1 bs=1 count=11400
dd if=/dev/zero of=inter2 bs=1 count=6902
\end{verbatim}
Ahora concatenamos todos con:
\begin{verbatim}
cat session1.iso inter1 session2.iso inter2 session3.iso > total.iso
\end{verbatim}
\item Se monta el fichero en loopback con una opción especial
A diferencia de cuando está en el CD donde el kernel puede preguntar
al lector sobre la última sesión disponible, ahora el kernel no puede
saber donde está el último encabezado iso9660.
Por lo tanto si queremos ver las sesiones superiores tenemos que dar
una opción a \texttt{mount} para decirle donde comienza la nueva
sesión. Esa sesión es \texttt{sbsector} \footnote{man \texttt{mount}}.
El comendo queda:
\begin{verbatim}
mount -o loop,sbsector=33498 total.iso /cdrom
\end{verbatim}
Y evidentemente se pueden dar especificar los otros sectores del TOC
por si se quiere montar sólo la segunda partición con la primera.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Extracción de pistas audio}
Este para acabar es muy sencillo. Yo recomiendo utilizar
\texttt{cdparanoia} ya que comprueba y hace reintentos cuando el audio
no se saca bien.
Para sacar en modo batch unos cuantos de ellos, el comando más
sencillo es:
\begin{verbatim}
cdparanoia -B -
\end{verbatim}
Los ficheros se guardarán con el nombre de \texttt{trackN.wav}.
Si queréis pasarlos a mp3 está el programa \texttt{abcde} que hace una
serie de operaciones en cadena recuperando la información de CDDB y
poniendola en las ID-TAGS de los ficheros.
\section{Conclusiones}
Hemos hecho un paseo por las diferentes opciones de grabación de CD's
corrientes (audio y datos). Ahora ya sabemos como aprovecharnos de la
multisesión.
Espero que este artículo haya aclarado las dudas siguientes:
\begin{itemize}
\item Por defecto cdrecord deja los CD's cerrados hay que ponerle la
opción \texttt{-multi} para que los deje abiertos.
\item Se pueden grabar datos en SAO y audio en TAO. En ambos casos es
la grabadora la que genera el Lead-In, Lead-out y los subcódigos.
La diferencia es que en SAO hay que pasarle por adelantado el TOC
mediante la CUE-sheet y codificar manualmente los silencios (si los
queremos).
\item SAO hace que el laser no tenga nunca que apagarse ni
reposicionarse al tener que generar el TOC de la sesión, lo cual
es una ventaja para ciertas grabadoras en fase terminal como la
mía.
\item \texttt{cdrecord} es perfectamente válido para grabar en modo
SAO. No es necesario utilizar \texttt{cdrdao}.
\item Si queremos enredar en el Lead-In, Lead-Out o en los subcódigos,
tendremos que utilizar el modo de grabación \emph{Raw}. Esto queda
fuera del alcance de este artículo.
\item SAO en principio no tiene porque impedir la multisesión, aunque
algunos firmwares opinen lo contrario (asociando SAO a DAO).
\item Los modos de pista \emph{CD-ROM 1 Mode 1} y \emph{CD-ROM XA
Mode 2 Form 1} son equivalentes en funcionalidad y ambos son
perfectamente aceptables para la multisesión o para la sesión única.
\item Las imágenes ISO en multisesión deben de estar ajustadas al
offset con el que se van a grabar. Si además se quieren incorporar
los ficheros de la sesión anterior, es necesario tener dicha sesión
a mano bien en el CD o bien en un fichero colocado en el mismo
offset que el CD.
\item El hecho de que un CD sea de arranque o no en x86 depende
únicamente de la imagen ISO.
\end{itemize}
\section{Me ha gustado mucho el artículo, pero no podrías también hablar de...}
\begin{description}
\item[DVDs] Todo un mundo aparte, otra organización de datos, sistemas
DVD+R y DVD-R, DVD's de video comerciales... La sección 4.4 de
\cite{mmc4} junto con el capítulo 4 de \cite{fuji} son un buen
comienzo para entrar en el ajo.
\item[UDF] Un sistema de archivos que se utiliza en los DVD's y que
seguramente habrá que considerar en el futuro. El estandar está
disponible en \cite{udf}.
\item[cdrdao, growisofs] Existen otras aplicaciones en linea de
comandos que probablemente puedan remplazar a \texttt{cdrecord}.
Nada como mirar sus páginas man.
\item[Interfaces gráficas]: k3b, graveman, xcdroast... sin duda
interesantes y de uso más común que la línea de comandos. Sin
embargo he preferido mostrar como las cosas funcionan un poco por
dentro y para eso no hay nada como la línea de comandos. Sería
interesante saber si estos programas proveen:
\begin{itemize}
\item Un sistema de traceo de los comandos que envían y reciben.
\item Si son front-ends de programas de consola que se puediera
ver y personalizar como llamar a estos programas.
\end{itemize}
\item[Proteccion de datos]: bonus-tracks y otras tristes irregularidades que
traen los CD's modernos para intentar limitarnos la copia privada.
Mi opinión: si los productores nos quieren poner barreras lo mejor es evitarlos :).
\end{description}
Todos estos son temas muy interesantes y animo a otros a que retomen
el camino y continúen en estas áreas.
\section{Agradecimientos}
Un agradecimiento especial a Diego y Nacho, los programadores del
nuevo proyecto \link{g4c}{http://g4c.sourceforge.net} por sus
referencias y correciones.
\begin{thebibliography}{LONGESTTIME}
\bibitem[CDFAQ]{cdfaq} Andy McFadden's CD Recordable FAQ.
\bibitem[FUJI]{fuji} Documento de Toshiba-Pioneer llamado ``Fuji''
aparentemente por el nombre del volcan..
\bibitem[MMC]{mmc} Drafts SCSI MMC en \link{t10.org}{http://www.t10.org/drafts}
\bibitem[MMC4]{mmc4} Ultimo draft de SCSI \link{MMC4}{http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r05a.pdf}
\bibitem[RED]{redbook} Philips Red book standard for CD-Digital Audio, 1980-85
\bibitem[YELLOW]{yellowbook} Philips Yellow book standard for CD-ROM
1, disponible en PDF como ECMA-130 en \link{ECMA}{http://www.ecma-international.org}{}
\bibitem[UDF]{udf} Especificación UDF de \link{OSTA}{http://www.osta.org/specs/}.
\bibitem[ISO9660]{iso9660} ISO 9660 File system standard, disponible
en PDF como ECMA-119 en
\link{ECMA}{http://www.ecma-international.org}
\bibitem[CDROMXA]{cdromxa} Philips CD-ROM eXtended Architecture
specification.
\bibitem[WHITE]{whitebook} Philips White Book for Video CD specification.
\bibitem[GREENBOOK]{greenbook} Philips CD-i specification.
\bibitem[MULTI]{multi} Multisession specification, Philips
\& Sony, 1995
\bibitem[TORITO]{torito} Estandar \emph{El Torito} para crear CD's
de arranque en ordenadores x86. Desarrollado por Phoenix y
disponible en \link{Phoenix.com}{http://www.phoenix.com/resources/specs-cdrom.pdf}
\end{thebibliography}
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
zación de datos, sistemas
DVD+R y DVD-R, DVD's de video comerciales... La sección 4.4 de
\cite{mmc4} junto con el capítulo 4 de \cite{fuji} son un buen
comienzo para entrar en el ajo.
\item[UDF] Un sistema de archivos que se utiliza en los DVD's y
también en algunos CD's y que también hay que considerarlo. El
estandar está disponible en \cite{udf}.
\item[cdrdao, growisofs] Existen otras aplicaciones en linea de
comandos que probablemente puedan remplazar a \texttt{cdrecord}.
Nada como mirar sus páginas man.
\item[Interfaces gráficas] k3b, graveman, xcdroast... sin duda
interesantes y de uso más común que la línea de comandos. Sin
embargo para ver y mostrar como funcionan las cosas por dentro las
interfaces gráficas tienen 2 lagunas:
\begin{itemize}
\item No proveen un buen sistema de traceo de los comandos que
envían y la información que reciben.
\item Si son front-ends de programas de consola no se puede
personalizar las opciones que envían a dichos programas.
\end{itemize}
\item[Proteccion de datos]: bonus-tracks y otras tristes irregularidades que
traen los CD's modernos para intentar limitarnos la copia privada.
Un tema interesante que requiere el dominio del modo Raw.
\end{description}
Todos estos son temas muy interesantes y animo a otros a que retomen
el camino y nos sorprendan con nuevos artículos :).
\section{Agradecimientos}
Un agradecimiento especial a Diego y Nacho, los programadores del
nuevo proyecto \link{g4c}{http://g4c.sourceforge.net} por sus
referencias y correciones.
\begin{thebibliography}{LONGESTTIME}
\bibitem[CDFAQ]{cdfaq} Andy McFadden's CD Recordable FAQ.
\bibitem[FUJI]{fuji} Documento de Toshiba-Pioneer llamado ``Fuji''
aparentemente por el nombre del volcan..
\bibitem[MMC]{mmc} Drafts SCSI MMC en \link{t10.org}{http://www.t10.org/drafts}
\bibitem[MMC4]{mmc4} Ultimo draft de SCSI \link{MMC4}{http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r05a.pdf}
\bibitem[RED]{redbook} Philips Red book standard for CD-Digital Audio, 1980-85
\bibitem[YELLOW]{yellowbook} Philips Yellow book standard for CD-ROM
1, disponible en PDF como ECMA-130 en \link{ECMA}{http://www.ecma-international.org}{}
\bibitem[UDF]{udf} Especificación UDF de \link{OSTA}{http://www.osta.org/specs/}.
\bibitem[ISO9660]{iso9660} ISO 9660 File system standard, disponible
en PDF como ECMA-119 en
\link{ECMA}{http://www.ecma-international.org}
\bibitem[CDROMXA]{cdromxa} Philips CD-ROM eXtended Architecture
specification.
\bibitem[WHITE]{whitebook} Philips White Book for Video CD specification.
\bibitem[GREENBOOK]{greenbook} Philips CD-i specification.
\bibitem[MULTI]{multi} Multisession specification, Philips
\& Sony, 1995
\bibitem[TORITO]{torito} Estandar \emph{El Torito} para crear CD's
de arranque en ordenadores x86. Desarrollado por Phoenix y
disponible en \link{Phoenix.com}{http://www.phoenix.com/resources/specs-cdrom.pdf}
\end{thebibliography}
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End: