Ir al contenido
Esta documentación describe la versión 4.0.0, todavía sin publicar. La versión actual en PyPI es la 3.3.0 y no incluye todo lo que se describe aquí.

Archivos

Todas las demás áreas de esta biblioteca parten de un array que ya está en memoria; esta trata de los archivos de los que ese array sale y a los que vuelve. Su premisa es que un archivo de audio producido por una cadena de medición es un registro de medición: las muestras solo significan algo junto a la frecuencia de muestreo, la calibración que convierte el fondo de escala digital en pascales, y la procedencia que dice dónde, cuándo y a través de qué se hizo la grabación. El módulo phonometry.io lee y escribe exactamente con eso en mente: nunca remuestrea, nunca mezcla canales, nunca normaliza y nunca toca un nivel, porque cada una de esas cosas es un valor por defecto documentado en algún rincón del ecosistema y cada una destruye en silencio la magnitud que una medición existe para conservar.

La forma práctica sale de un repaso al equipamiento, no de coleccionar formatos. Sonómetros y grabadores de campo emiten WAV lineal: PCM de 24 bits, WAVE_FORMAT_EXTENSIBLE para el multicanal, metadatos BWF bext, RF64 cuando una grabación nocturna pasa de 4 GiB. Así que la instalación base (NumPy y SciPy, nada más) lo lee todo, y los formatos comprimidos viven tras el extra opcional [audio] (python-soundfile, cuyo wheel empaqueta libsndfile bajo LGPL-2.1). Las fuentes con pérdidas se leen pero se señalan, a las claras: un nivel calculado sobre la aproximación ADPCM o MP3 de la forma de onda no es defendible, y el aviso más la marca lossy mantienen ese hecho pegado a los datos.

Lo que vuelve de un archivo es un Signal (io.Signal, o phonometry.Signal; el módulo donde está definido es privado): las muestras con su frecuencia, su calibración, sus etiquetas de canal y su procedencia bext en un único objeto inmutable que se comporta como el array desnudo en todas partes (np.asarray entrega las muestras a cualquier función existente), se dibuja solo con .plot(), y entra directo en las funciones de nivel (leq, laeq, ln_levels, sel, lc_peak, sound_exposure, lex_8h) sin repetir a mano ni la frecuencia ni la calibración. En la otra dirección, write() produce WAV/BWF (el de 24 bits empaquetado en casa) y FLAC, se niega a recortar en silencio, extiende el CodingHistory en vez de sustituirlo, puede medir los cinco valores de sonoridad EBU R 128 del bext versión 2 con la implementación propia de la BS.1770, y deja la calibración en un pequeño sidecar JSON versionado junto al audio: el número para el que ningún contenedor de audio tiene campo, hecho para viajar.

Los otros archivos que la biblioteca lee y escribe son catálogos de materiales. La biblioteca publica las tablas de sus libros y normas y ninguna de un fabricante, así que una hoja de características, una declaración de prestaciones o un informe de ensayo propios van en un archivo tuyo, un documento JSON o una hoja de cálculo guardada como CSV con una cabecera JSON al lado, con la procedencia del documento: su tipo, su versión, el día en que lo consultaste, el laboratorio y el informe. read_catalogue lee ese archivo en filas de las mismas clases que entregan todos los catálogos publicados, de modo que el núcleo poroso de tu hoja de características entra en medium() igual que uno de un libro, y una cifra que la hoja de características imprime en kPa·s/m² o en centímetros se convierte a partir de sus dígitos y queda anotada tal como la imprimió. Los problemas de un archivo se informan juntos, cada uno en su lugar del archivo, y nada de lo que el archivo nombra se importa nunca. write_catalogue escribe un catálogo de vuelta, y escribe una tabla publicada con la misma forma, como plantilla de partida. catalogue_schema escribe el esquema JSON de un archivo así, para que un editor lo complete mientras lo escribes y marque lo que el lector rechazaría por su forma; el sitio publica el esquema de todas las clases de fila que publica la biblioteca.

  • Leer y escribir audio de medición: todo el flujo en una página ejecutable: leer el WAV de un sonómetro en un Signal calibrado, derivar la calibración de la toma del calibrador, el aviso de pérdidas y la historia de las copias de escucha que hay detrás, recorrer por bloques una grabación nocturna con filtros con estado, escribir BWF con su procedencia, el viaje de ida y vuelta del sidecar, y una conversión con la que la medición no deja de serlo.
  • Tus propios catálogos: una hoja de características, una declaración de prestaciones, un informe de ensayo o una medida tuya como archivo de catálogo: una tabla publicada como plantilla, el documento y su procedencia, una hoja de cálculo guardada como CSV, los rechazos que señalan una celda, las filas en los modelos y en todas las búsquedas por nombre, qué clase de fila guarda cada magnitud y el esquema JSON con el que un editor completa un archivo. Qué es cada número de una hoja de características, antes de teclearlo, está en Cómo leer la hoja de características de un material, entre las guías de materiales.
  • Ni reproducción, ni edición, ni efectos. Esto es una capa de archivos para mediciones, no una estación de trabajo de audio: nada de aquí reproduce un sonido, recorta una región a oído ni aplica ganancia. Tampoco hay escritura con pérdidas, a propósito: ninguna medición termina en un MP3, y una biblioteca cuyo trabajo es conservar niveles no debería ponerlo fácil.

  • El AAC/M4A se queda fuera. Las grabaciones de dictáfonos y teléfonos en contenedores MP4 no se descodifican; la vía honesta es una línea de ffmpeg -i note.m4a note.wav y después read(), con la misma advertencia de pérdidas en ambos casos. Igual con los formatos de adquisición que no son audio: TDMS (LabVIEW) y UFF (análisis modal) tienen sus propios lectores en Python, npTDMS y pyuff, y fingir que son archivos de audio no serviría a nadie.

  • Los archivos ambisónicos se toleran, no se interpretan. Un .amb en B-format o un GUID ambisónico se lee sin problema y sus canales vuelven etiquetados, pero no se aplica ninguna matriz de conversión FuMa a AmbiX: el canal 0 de un archivo FuMa lleva W a −3 dB, y convertirlo en una presión sin decirlo sería un cambio de nivel silencioso. Es exactamente la clase de valor por defecto que este módulo existe para rechazar.

  • La biblioteca no trae datos de fabricantes. Una hoja de características se revisa sin cambiar de título, sus condiciones rara vez permiten copiarla, y el valor que necesita un proyecto es el de la hoja de características con la que se especificó, así que tus catálogos se quedan en tus archivos y en los objetos que devuelve read_catalogue: la biblioteca no guarda ninguna copia ni abre ningún enlace que nombre un archivo. Por lo mismo, una tabla de un fabricante pegada en una issue o en una pull request nunca se incorpora.

Antes: Calibración y dBFS explica de dónde sale de verdad el factor de calibración que lleva un Signal, y Primeros pasos pasa un primer archivo por la cadena. Después: todo lo demás. El sentido de la capa de archivos es que los niveles, el filtrado en octavas, el proceso por bloques y el resto de la biblioteca reciban una señal calibrada sin enterarse nunca de que salió de un archivo.

Si llegaste aquí desde una búsqueda y quieres la forma de toda la biblioteca, ¿Qué necesitas medir? la indexa por el trabajo y Todas las guías lista cada página con una línea sobre cada una.