External Data Sources #36
Comments
|
On the other hand, tagging music is hard and beets does it really well. Maybe, we could work on interoperability with beets. Some way to import your hand tagged beets collection into forte. |
|
Here's an example of the data exposed by the beets export plugin: It seems to be missing the path. This was generated by running: The schema of beets can be found https://github.com/beetbox/beets/blob/3373b090bdae9bbc9ffb3653beb8553498e3c845/beets/library.py#L421-L493 Both the item and album seem to be available, but only the items are exposed. The database is stored in the beets config folder in the CREATE TABLE item_attributes (
id INTEGER PRIMARY KEY,
entity_id INTEGER,
key TEXT,
value TEXT,
UNIQUE(entity_id, key) ON CONFLICT REPLACE
);
CREATE INDEX item_attributes_by_entity ON item_attributes (entity_id);
CREATE TABLE albums (
id INTEGER PRIMARY KEY, artpath BLOB,
added REAL, albumartist TEXT, albumartist_sort TEXT,
albumartist_credit TEXT, album TEXT,
genre TEXT, year INTEGER, month INTEGER,
day INTEGER, disctotal INTEGER, comp INTEGER,
mb_albumid TEXT, mb_albumartistid TEXT,
albumtype TEXT, label TEXT, mb_releasegroupid TEXT,
asin TEXT, catalognum TEXT, script TEXT,
language TEXT, country TEXT, albumstatus TEXT,
albumdisambig TEXT, rg_album_gain REAL,
rg_album_peak REAL, r128_album_gain INTEGER,
original_year INTEGER, original_month INTEGER,
original_day INTEGER
);
CREATE TABLE album_attributes (
id INTEGER PRIMARY KEY,
entity_id INTEGER,
key TEXT,
value TEXT,
UNIQUE(entity_id, key) ON CONFLICT REPLACE
);
CREATE INDEX album_attributes_by_entity ON album_attributes (entity_id);This information was gathered with beets 1.4.7. There are a couple of things we could do to integrate with beets.
|
Still need to decide whether the best input to this program is a file. See #36.
|
It looks like the path is removed from one of the representations. https://github.com/beetbox/beets/blob/db782a2404fa8a6827c10a6536b4a960d19af135/beetsplug/info.py#L69 It still returns the internal item where the data is generated. I think we should opt for 2 because it is a less leaky abstraction. This would require creating a new plugin and injecting at runtime into a beets instance. |
|
I've reached out to the beets community to see how they would like to go about this. https://discourse.beets.io/t/better-interoperability/460 |
|
The beets community hasn't been very responsive to our idea. If I were to guess why the path isn't returned, it is probably because paths are byte arrays and hard to represent in json. If we wanted to take advantage of beets, we should probably just make our own beets plugin. |
|
Integrating with beets will take about as much code as just ripping the important ideas from beets and putting it into our thing. It seems like beets does the following:
I don't think we need this now. Maybe later. |
Currently, the only data used to index files, is data from the songs tags and files around the song. This doesn't seem to be enough (#18, 8e9ae36, #31).
Our plan so far has been to assume the music is well tagged. Even my collection doesn't seem to be well tagged. For forte to work, we need to have good metadata about audio and rich album artwork. For these reasons, we should consider pulling data from external sources (like musicbrainz and AcoustID).
The downside is that importing would be slower. Currently it takes about 15m to import 3k items stored on a NAS. Using AcoustID would mean that importing this many items would take 16m just to request the data from the AcoustID server (probably the main bottleneck). The old way could be hidden behind a flag.
The quality and reliability musicbrainz, acousticid and coverartarchive is really good compared to what it was before. I think it is worth the extra import time to have good data. Also, it goes with the requirement that input files will not be mutated, will still providing a good experience.
The text was updated successfully, but these errors were encountered: