Instead, its best to think of TRM as a system that lets you guess which few dozen tracks a file could be matched to - there is a lot of logic in the tagger that makes up for the shortcomings of TRM. Given this, TRM is not some sort of magical solution that with great authority tells the tagger what metadata to apply to a track. One example TRM (non silence on page 2) has 104 tracks associated with one single TRM. For example, take a look at the TRM’s with at least 5 tracks report: 4400 pages (!) of TRMs that I would consider to be sub-optimal. The fact that this problem hasn’t reared its ugly head to the public, is a testament to Dave Evans’ skill in keeping the TRM server ticking.įurthermore, TRMs have shown themselves not to be as unique as we would’ve liked. Thus our server has 5GB of RAM and it still can’t keep up.
In order to make the TRM server perform at some reasonable level of performance, the entire database needs to be kept in RAM. To prevent crashes, we prune the database where we throw out the least used TRMs, which implicitly discards work that our users have done. The TRM (TRM’s are acoustic fingerprints that MusicBrainz uses to identify music tracks) server is constantly overloaded and can only handle a database size of about 2.2Gb before it crashes. I’ll start off with TRM, since that is hot discussion topic on the musicbrainz-users mailing list right now.
Musicbrainz picard all untagged update#
This general update is way overdue - a lot of things have been happening behind the scenes and its time to let everyone know where things in the MusicBrainz world are headed.
0 kommentar(er)
