Re: tag editing

[Yoni Rabkin]

Grant Shoshin Shangreaux <grant@churls.world> writes:

>>> 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.

That is all par for the course, as they say. Don't worry about the
timing. We get to determine when a release comes out.

>>> 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
> tags...done".
>
> 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.

This is a good thing to do, and I would like to see it
implemented. However, it doesn't replace validation (more on this
below.)

> 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

There are three levels of error to handle: first is when `call-process'
cannot find an executable, second is when the executable ran but
returned an error (redirecting and looking for output in the
standard-error stream may help here in well behaved executables), and
finally when the executable ran without error but didn't do the job we
wanted. This final one is addressed below.

> 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 :)

Validation is important for Emms to become dependable as a tag
editor. But don't worry overly much about creating robust testing; if
you are doing all of the development yourself you can, and should, rely
on the rest of us to hammer your code. Send it out to a branch on the
repo and ask us to throw stuff at 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 :) )

I'd take Petteri's word on this.

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

Looking forward to it.

-- 
   "Cut your own wood and it will warm you twice"