[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tag editing

From: Grant Shoshin Shangreaux
Subject: Re: tag editing
Date: Sun, 14 Mar 2021 15:08:14 -0500

>> working on getting my FSF assignment finished and looking forward to
>> contributing to the project soon.
> That is good to hear; thank you.

sorry about the delay, it took quite a while to get the attention of my
employer to finish the process. i truly hope i'll be clear before the
next emms release, as i have a few minor contributions i hope to provide.

>> the files i tagged no longer had the
>> metadata the when i opened them in another program.
>> i'd like to fix that silent failure,
> This is a priority and would form a basis for all further tag editing
> work. It would be great if you started there.
> We would want that, if the tag editor is calling an executable, that a
> failed process call would fail loudly.
> Then we want that regardless of how the tags are being written, natively
> or with an external process, that the editor would check if the tag had
> indeed been updated in the file by comparing the tags in the file before
> and after update. Trust, But Verify.

i've done some work around this issue, and it looks like rather than a
failed executable process, the problem is that there is no tagfile
function configured for the Opus file type. only mp3, ogg, and flac are
supported. EMMS just skips trying to write to the files, but updates the
cache with no problem and the only message a user sees is "Setting

my proposed solution is to warn the user before even loading metadata
into the tag editor. if a single track is selected, trying to edit an
unsupported format (no match in the emms-tag-editor-tagfile-functions
variable) will NOT open the tag editing buffer and instead issue a
warning message that there is no tag writing function configured. this
can be overridden with the universal argument if a user wants to edit
tags anyway, knowing that at least EMMS can save them in the cache. if
the track is not a file, it allows the user to edit metadata regardless
(for example, you want to add data to a url track). if multiple tracks
are marked and you try to edit the metadata, any unsupported files
will not appear in the tag editor buffer and a warning message will
appear. the universal argument again will allow tag editing anyway.

what do you think about this option? its based primarly in my own
experience of the application and what i would have liked to have happen
as i was tagging a handful of opus files.

i've yet to handle cases where the executable fails, as is i think it
only puts a message into the EMMS log. i'm not sure what the "best" way
to handle this is, especially when writing to multiple files. i'll
continue working on this

i also still need to do the verification of tag updates after it
happens. i'm working on writing up some ert tests to make it a bit
easier to ensure, my plan was to generate some test audio files for the
tag editor to operate on. i'm not sure if its practical to set up
automated testing for EMMS at large, but at least on my local machine it
will help me progress on this. please let me know if you have any
thoughts about it :)

>> but i also started digging around for a solution for writing tags to
>> all formats. unfortunately, there isn't a simple tag writer included
>> with the opus-tools package. you must re-encode the audio to add
>> tags. so far, i've found 3 candidates
> Re-encoding is a no-go.
>>   1. add a shim for TagLib to write to files (beyond me at the moment)
>>   2. opuscomment[1] tool (must be built from source)
>>   3. audiotools package's tracktag program[2]
> Packages such as audiotools are themselves abstractions to C libraries
> such as libmpg123, libdvd-audio, etc. (like tinytag, which Emms calls).
> We likely aren't going to ask to have any of those C libraries be linked
> to Emacs on compilation, so the best scenario is indeed native reading
> and writing, and that is a worthy goal.

i've been testing out my wrapper for tracktag with decent success so
far. i hope to also contribute that to EMMS as it provides a "one tool
fits all" tag writer that can be installed by a package manager. i still
like the idea of a TagLib shim, but for the time being this works for
me. Petteri suggested that native writing may be a much bigger job than
is worth it for Elisp, though that would be ideal (assuming it can
manage to update precious files without error :) )

Thanks for all the work on the project, once again I hope soon to make
some real contributions!

- Grant

reply via email to

[Prev in Thread] Current Thread [Next in Thread]