Caso de estudio: sonido para Web: Soprole / Queda Poquito

La Web es multimedial; siempre ha podido serlo. Pero ha tomado tiempo que los estándares –reales o de facto– y el rendimiento de conexiones y aparatos de clientes estén a la altura. Hoy ya está pasando, y es una oportunidad interesante para la comunicación y para la profesión.

Por encargo de Initiative, canal.cl desarrolló un conjunto de piezas sonoras para un proyecto interactivo asociado a un producto Soprole: un juego online, construido en Adobe Flash, que simula la visita a una casa embrujada, llamado Queda Poquito.

El desafío era interesante: generar sensación de lugar desolado, con elementos de ambiente e interacción identificables pero no extensos, ya que el ancho de banda, tiempo de descarga y rendimiento son factores importantes en una entrega vía Web.

Quiero compartir algunas claves importantes que ayudaron al éxito:

• Debido al contexto del usuario (parlantes pequeños, acceso en espacios compartidos), no podemos usar todos los trucos y sutilezas de un diseño sonoro audiovisual tradicional. Clave es diferenciaciar entre sonidos de primer plano y segundo plano.
  
  
• El diseño sonoro de un proyecto interactivo pasa por el diseño total, y por lo tanto al proyecto se le debe asignar el cargo de director, similar al caso del audiovisual, aunque no se le llame de la misma manera, tiene que estar claro quién define la estética general, el rol del sonido, la estructura de navegación y –en este caso– la manera en que esa estructura se relaciona con la metáfora de un lugar físico.
  
  
• Habría sido fácil usar una biblioteca comercial de sonidos para copy & paste, pero existe el riesgo de que el resultado suene igual que todo lo demás. Por eso todas las piezas de este proyecto contienen combinación de material de biblioteca altamente modificado y material original.
  
  
• El material original se grabó con un sistema portátil 96KHZ/24 bits. El Tascam DR-100 es una excelente opción, capaz de conectar con micrófonos profesionales como los Earthworks SR25 que usamos en este caso.
  
  
• Antes de iniciar la creación de las piezas sonoras es importante definir formatos técnicos adecuados. No tiene sentido –por ejemplo– trabajar a 96 KHz si un proyecto se va a entregar a 44.1 o 32 KHz. Importante porque la conversión afecta la velocidad del trabajo grupal al intercambiarse versiones por vía electrónica, y también perjudica la calidad.
  
  
• A propósito: como en cualquier proyecto de software es importante una nomenclatura clara de control de versiones, y mantener coherencia con archivos relacionados. Por ejemplo, si el video la portada se llama video_portada_01 el audio podría llamarse video_portada_01_audio_v01 para evitar problemas con cambios paralelos de versiones.
  
  
• En este caso usamos un directorio compartido en la "nube" donde iban quedando todas las versiones, al que todos los miembros del equipo tenían acceso, de manera que podíamos usar URLs, facilitando el trabajo multiplataforma, la comparación de cambios y evitando tener que enviarse archivos de audio por e-mail.
  
  
• Un consejo en relación al trabajo multiplataforma: no todas las herramientas de autoría cortan medios de la misma manera, se necesita un poco de ensayo y error para calzar loops en distintas aplicaciones, y es recomendable que el audio entregado dure un poco más que lo solicitado, de manera que quién está armando el compuesto final tenga margen para cortar a su voluntad.

Siguiendo estas premisas, pudimos hacer un flujo de trabajo muy expedito y preciso con la gente de Initiative, lo que redundó en resultado de excelencia en tiempo récord, el cliente está contento y ha tenido bueno respuesta de parte de los usuarios.

¿Diseño de Sonido Centrado en el Usuario?

¿Qué pasaría si aplicamos el Diseño Centrado en el Usuario al diseño sonoro? ¿Cómo tendría que ser el Diseño de Sonido Centrado en el Usuario?

Aunque a la rápida y sin aplicar metodología formal, es en alguna medida lo que hicimos con Initiative. Repasamos la experiencia en las distintas salas de la casa embrujada, y en un proceso iterativo mejoramos el componente sonoro en base a lo experimentado cada vez.

Lo hicimos como especialistas, no como usuarios, por lo tanto fue más parecido a un contexto de test heurístico que a un estudio de usuarios formal. Pero sí aplicamos –como mencioné antes– el poner atención acerca de quién es el usuario y cuál es el contexto en que usará la aplicación.

Como resultado de esta experiencia, me estoy planteando la posibilidad de ensayar una metodología formal de Diseño de Sonido Centrado en el Usuario. Otro desafío, porque el tiempo en este caso no lo habría permitido, y tuvimos que usar más el sentido común y la experiencia. Pero quedó hecha una interesante pregunta.

Mis agradecimientos a todo el equipo en Initiative y en particular a Claudio Bruna por la confianza.