Write audio tags back into files#728
Write audio tags back into files#728daschuer merged 57 commits intomixxxdj:masterfrom uklotzde:WriteAudioTags
Conversation
There was a problem hiding this comment.
This was intentional at the time since some people use Browse instead of the library and we want to let them edit the tracks in a way that persists across sessions and we didn't want to edit the files on disk by default unless the user opts in to that.
There was a problem hiding this comment.
I will delete the question and move the comment (including your remarks) to
the corresponding invocation to reveal this intention.
On 12/27/2015 05:49 PM, RJ Ryan wrote:
In src/library/browse/browsetablemodel.h
#728 (comment):@@ -37,35 +37,42 @@ const int COLUMN_REPLAYGAIN = 20;
// The BrowseTable models displays tracks
// of given directory on the HDD.
// Usage: Recording and Browse feature.
+//
+// NOTE(uklotzde): Accessing tracks from the browse view willThis was intentional at the time since some people use Browse instead of
the library and we want to let them edit the tracks in a way that persists
across sessions and we didn't want to edit the files on disk by default
unless the user opts in to that.—
Reply to this email directly or view it on GitHub
https://github.com/mixxxdj/mixxx/pull/728/files#r48456406.
|
hey im a complete noob about all these branches, compiling and stuff |
|
You definitely need some knowledge about how to set up a development http://mixxx.org/wiki/doku.php/start#developer_documentation If you don't want to do any development yourself you can simply clone my git clone https://github.com/uklotzde/mixxx.git ...and then start the build as explained in the Wiki. On 02/20/2016 01:25 PM, Alibaobao wrote:
|
|
thanks for your work and help |
|
Glad to hear you managed to compile it :) Please note, that I rebase this I'm using this version for keeping my tags in sync with the library. Editing If you have some feedback, e.g. on how to name or describe the two new On 02/20/2016 03:56 PM, Alibaobao wrote:
|
|
I use your build because i don't want an external beat-analyzer |
|
What do you mean with "normal Version"? Both bpm and key are written into tags. You can explicitly overwrite the file tags with the metadata from your On 02/21/2016 07:05 PM, Alibaobao wrote:
|
|
Further discussions about the topic can be found in this closed PR: This solution works fine for me and is safe. But we need to figure out how to handle existing libraries with inconsistencies or duplicates. |
|
Just wanted to let you know I've been using this branch (local build) for a few days now and haven't encountered any serious issues. Here are two notes/questions I'd like to share with you:
|
|
UI freezes are a general issue in Mixxx, because all the library management Unfortunately there is no common standard for saving ratings in tags, so I On 03/21/2016 10:43 AM, Tobias Nett wrote:
|
|
take a look at the new track exporter code for an idea of how to do non-blocking library operations in a separate worker thread. That code still uses a modal window, but the important part is it's not too hard to make sure the write-to-disk operations don't happen in the UI thread. |
|
But write-to-disk operations occur individually for each track and cannot be On 03/21/2016 03:24 PM, Owen Williams wrote:
|
|
how long do these writes usually take? Would it be possible to flip a flag in the TIO that prevents the track from being loaded while the write is in progress? A boolean indicating a lock, basically. We could gray the track out in the library while it's being written. For bulk operations, a modal window with progress bar seems reasonable. |
|
The library gets updated in the same moment which also involves a write But the write operations have never been an issue for me. Doing bulk updates On 03/21/2016 03:43 PM, Owen Williams wrote:
|
|
So there are two writes going on -- writing to the library and writing the track metadata. The library is an sqlite database, and sqlite does its own caching and disk access so it's going to be fairly efficient. Writing the audio tags involves us mutating track files on disk ourselves. My interpretation is that the new UI freezes are caused by the writes to the track files, not the library database. Therefore I'm talking about putting a "lock" on the track entries so the tracks can't be loaded while the metadata is being synced, and then moving that syncing to a separate thread. If the UI freezes we are talking about are totally unrelated to this PR, then that's a separate bug that should be discussed in its own report. But @skaldarnar seemed to say that something in this PR specifically is causing more UI freezes, and that's what I'm trying to figure out. If metadata syncing is being done in the UI thread, I think that's a bad design choice and we should use techniques like I mentioned to avoid it. Bulk updates will happen while exiting the program and the whole cache gets cleared at once. |
|
Most bulk operations on tracks are currently causing UI freezes. That's an There still is an unfinished "Library concurrency refactoring" PR from a On 03/21/2016 04:01 PM, Owen Williams wrote:
|
|
That is on my list. (After all my other projects are merged) |
|
Thanks for clarification on the UI freezes. Good to know it is a general issue and that you are aware of the problem. @uklotzde Thank you for the hint to write additional information into the comment field. Is it possible to sort your library by the rating in the comment field somehow? What do you think about setting (kind of arbitrary) numbers for the rating if the user wants to (opt-in in the preferences) as mentioned on the wikipedia page? |
|
ok, I'll give this PR a try and see if I notice any additional freezes while writing track metadata. |
|
What is the status of this? |
|
I'm using this version to keep my files in sync with the library. Please On 07.11.2016 11:07, Conner Phillips wrote:
|
|
I meant in regards to being merged. Any timeline prediction on that? |
|
Oops. I accidentally pushed some changes while testing the loop escape PR. Fixed. |
|
LGTM thank you! @daschuer, ready for merge? |
|
Yes, we can merge. Juchhu! Thank you so much! Now I can consider to ditch Clementine for metadata. |
|
Thank you both so much for reviewing this beast! I'm curious to get some real-world user feedback. It's always sensitive to modify a user's own private data. ...now let's get the post-fader effects ready ;) |
|
Yes! |
|
This is awesome. Thanks so much for your work on this Uwe! I am really happy to see this in mixxx The next thing missing regarding metadata in / out and improving mixxx + other app compatibility and what would be highly helpful to me personally is star ratings, which has a PR but it doesn't look as if active development is happening: #1089 |
|
Very exciting! Definitely going to test this asap (dw, I have backups! haha) |
|
Vorbis -> MusicBrainz style comments: If anyone needs help with converting DESCRIPTION into COMMENT fields in FLAC files safely, just ask me. I'm preparing a shell script using metaflac to analyze and cleanup my collection. I don't have any OggVorbis files, but the proceedings should be similar. |
|
Awesome work @uklotzde, @daschuer and and @Be-ing we finally have it in master 👍 By the way: It's really nice to see that mixxx gains some pace in development - looking forward for a new beta release to update some friends 👍 I'm already using current master for noncritical daily work |
|
@MK-42 It would be overkill to save tags (including a backup file copy) after every field edit, impossible. Tags are only saved if the corresponding cached track object is destroyed, i.e. when it is evicted from the in-memory cache. You may have noticed the message box that popped up when enabling this feature 😉 Exporting tags is a very costly file operation that might introduce some latency within the main tread due to lock contention on the cache. We already have a follow-up PR trying to minimize this impact. There is also a serious issue with the initialization order on startup that needs to be fixed. |
I followed your discussion here and were aware of that fact. But I was unsure if there is some cached track object for that track if it is not loaded to any deck/sampler and expected an immediate write operation in that case. That changing the focus in the table triggers the export was unexpected for me and I was unsure if that could be a bug. If thats expected behavior, everything is alright 👍 |
14 participants
Re-enables writing of metadata into files:
https://bugs.launchpad.net/mixxx/+bug/728197
Related bugs:
https://bugs.launchpad.net/mixxx/+bug/1156868
https://bugs.launchpad.net/mixxx/+bug/687293
https://bugs.launchpad.net/mixxx/+bug/1181869
Contains lots of fixes around TrackInfoObject including caching of TIOs to safely manage all references of a file. I'm already using a version of Mixxx built from this branch for myself. It has proven to be very stable and I only discovered and fixed some rare edge cases (like hide + purge + rescan while a track is still cached) recently.
New preferences for "Library" in section "Audio File Tags"
"Update track meta-data in library by reloading audio tags from files"2016-06-24: Considered experimental and moved into another branch. Has some nasty side-effects when selecting and loading multiple tracks at once.The 2nd option should only be enabled after all files are in sync with your Mixxx library! Otherwise the information stored in your Mixxx library gets updated/overwritten whenever Mixxx accesses a file. A warning message will appear if you enable this option to prevent users from unintentionally selecting it.2016-06-24: Considered experimental and moved into another branch. Has some nasty side-effects when selecting and loading multiple tracks at once.New context menu item (mainly for migration purposes):
What's missing (optional):
I've finished to separate my modifications into commits that are hopefully reviewable now. The changes are numerous! Even if the refactoring is not completely finished I'm already very happy with the end result. Now I can use Mixxx to manage my music library except when I need to edit the properties of multiple tracks at once.
Note
I will rebase and edit this branch frequently until we agree that it is mergeable ;) That's the reason for tagging this PR with [PREVIEW]