Software para editar metadata de archivos Flac

[Colchaguino 14]

Se ve prometedor Picard.

Usé en su tiempo Tag&rename pero no estoy dispuesto a pagar de nuevo una licencia

[diegoabarcar 18]

Yo tengo el tagandrename con licencia de no se cuando. Me gusta la conexión que tiene con discogs para descargar metadata.


Enviado desde mi iPhone utilizando Tapatalk Pro

[pbanados 930]

Hola, he estado revisando un poco a la rápida el MusicBrainz Picard, y al parecer es la raja... por fin una BD relacional para la música (al parecer usa el SQL Postgres), casi todos los demás son BD planas, donde las posibilidades de ambigüedades o duplicidad de información son casi infinitas (10 nombres distintos para le mismo artista, por ejemplo). Pero, ayuda los expertos:

1- Si uno tiene su librería de música en un programa que la maneja, tipo jRiver o Audirvana, hay alguna manera de integrar en ese programa la metadata editada en MusicBrainz? O de manejar la librería y reproducir la música mediante algún comando desde el propio Picard?

2- Se puede manejar no solo archivos digitales que uno tenga, sino también registrar otros, como por ejemplo lo que uno va escuchando por streaming?

3- Otra: si la BD de MusicBrainz es tanto más potente, consistente y de uso público (e implementa cosas obvias que los otros no, como las "huellas digitales" de artistas, discos o tracks, una consecuencia obvia de usar BD relacionales por lo demás, debe ser el campo índice de cada tabla), por qué todos los programas de librerías o streaming usan esa mierda de GraceNote, que es un verdadero caos, responsable de todas las inconsistencias de búsqueda en Tidal o Apple Music o Spotify?

Grx!

 

[pbanados 930]

Estoy entendiendo un poco más el asunto: el musicbrainz es como una wikipedia de música (y su contenido está almacenado centralmente en BD relacionales Postgres). Cuando editas la metadata con Picard, reescribes el header de metadata de tus archivos. El contenido escrito es chequeado en esas BD centralizadas, lo cual minimiza (pero no elimina) las inconsistencias típicas de los programas que editan la metadada directo, sin chequeo de la info centralizada, que son prácticamente todos los demás. No la elimina porque igual esa metadata queda independiente de las BD centrales, y por lo tanto, propensa a inconsistencias posteriores con nuevas ediciones.

De lo anterior se deduce que aún con Picard, la data que se lee de un disco o track sigue siendo la metadata grabada en el archivo, y no una información re-estructurada en forma relacional. Por lo tanto, a) solo sirve para archivos digitales tuyos y no contenido adicional (tus vinilos, tus escuchas por streaming); y b) es agnóstico de la app con que se reproduzca la música, que siguen mirando la data almacenada en el mp3, flac o lo que sea, en vez de una BD central.

Si hay un error en lo anterior, agradecería mucho una aclaración. El tema es muy interesante.

[pbanados 930]

Esto es interesante.

El esquema de la BD postgres de MusicBrainz. Incluso para los tuercas hay un github con los script SQL para generar todo el esquema con tablas, triggers, stored procedures, llaves, etc. Las tablas amarillas son de poca mutabilidad (+- estáticas); las calipso son las tablas primarias, y varias de estas primarias tienen una tabla "alias", para registrar variaciones de nombre del mismo artista, sello, etc.

 

Para los que cachen de bases de datos, creo (aunque no estoy seguro) que en este mismo esquema queda claro la razón de un problema recurrente que tienen los programas de streaming o bibliotecas: cuando el mismo artista existe en variaciones (ej: "Anouar Brahem" / "Anouar Brahem Trio" / "Anouar Brahem, John Surman, Dave Holland" / etc) cada una de esas variaciones son identificadas como un artista distinto (artist:id). Cuando buscas a "Anouar Brahem", te aparece la primera y no las otras. Si quieres encontrar todos los discos de Brahem, tienes que saber por anticipado todas las formaciones en la cual Brahem es el artista principal. 

Según entiendo, varias BD relacionales y específicamente la Postgres en que está almacenado MusicBrainz, soportan llamadas recursivas en la misma tabla o mediante una tabla hija. Por ejemplo, si existiera una tabla "Artist_detail", esta podría contener los miembros "artist" de ese artista (la tabla tendría que tener un campo para identificar el artista principal): en la tabla "artist" está "Anouar Brahem, John Surman, Dave Holland" como una identidad con su ID único (pongamos, el #101); además está Brahem (id #201), Surman (id #212), Holland (id #345). En la tabla "artist_detail" habría una FK con el nombre del artist, y otro FK con el miembro. Para el artista #101 (Brahem, Surman,Holland) habría tres entradas en la tablas "artist_detail":  (#101, #201, T) (#101, #212, F), (#101, #345, F), con el detalle de los miembros de Brahem/Surman/Holland y cual de ellos es el principal ( el campo booleano).

En ese esquema, la búsqueda de TODOS los discos de Brahem se haría con una stored procedure (o quizás solo una view  con un join +- largo de tablas) que busque no en la tabla  "artist", sino en "artist_detail" las entradas con el id del artista que te interesa (#201 en este caso), y que tenga el booleano en TRUE.

Si alguien sabe más de BD podría abundar/corregir  sobre esto, y eventualmente sugerirlo a MusicBrainz.

---

En estas tablas centralizadas del esquema de arriba es donde musicbrainz busca consistentemente la metadata que escribirá en cada archivo. Lo que yo me pregunto es por qué aún hoy, en que nadie funciona sin internet, se sigue manteniendo la metadata incrustada en los archivos de música en vez de simplemente almacenar el ID del disco y de cada track, y buscar en esta BD central el detalle asegurando así consistencia de la información que se maneja. Todo este pajeo de editores de metadata como el Picard es para paliar la complicación de seguir manteniendo la data atomizada en cada track de tu librería.

Sorprendentemente, hasta donde sé no existe NI UN SOLO PROGRAMA de librerías (y menos de streaming) que haga una manejo relacional de la data, en vez de esta cosa antediluviana de tenerla que sacar una y otra vez de los propios archivos, y sin nada -por arquitectura- que garantice la consistencia de la data.

 

 

Editado January 22, 2021 at 19:16 por pbanados

[pbanados 930]

Eventualmente algún informático del foro le interesara (o se espantará) con esto... por ahora me siento hablándole a la pared....

Otra cosa interesante de MusicBrainz es que se puede bajar la base de datos completa si uno la quisiera correr en un servidor de BD local; incluso se puede implementar replicación de la BD para mantener un "live data feed", para que tu instancia local de la BD esté al día respecto del repositorio central.

Y otro asunto de interés es que al parecer se pueden enviar comandos a algunos programas de librerías para que, por ejemplo, puedas disparar que se toque un disco desde el propio Picard o alguna app que uno construyera. Jriver soporta estas llamadas remotas.

La suma de los dos anteriores significa que, eventualmente, alguien bien tuerca podría implementar una app (por ejemplo mediante python y complementos SQL) para manejo relacional de la BD, y luego tocar la música seleccionada en jriver (o mediamonkey, u otro) mediante comandos remotos enviados desde esa app.  

Editado January 23, 2021 at 00:36 por pbanados