Re: [PATCH] Add: tracktag interface and support for Opus

[Yoni Rabkin]

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

> Yoni Rabkin writes:
>
>> The emms-tracktag should be changed to emms-info-tracktag in order to be
>> consistent with the rest of the info methods.
>
> the tracktag tool is specifically for writing tags. there's a separate
> utility for reading info, but i hadn't planned on integrating that at
> this time. audiotools does look fairly handy, so if there were desire to
> enhance EMMS's features with some of its utilities, that is something I
> could certainly work on. For now, I really just wanted an Opus capable
> tagger. Its unfortunate there didn't seem to be a good stand alone
> option for it (opustools unfortunately doesn't include a tagger, unless
> you want to re-encode the file).

That puts us in a dilemma since other info backends, such as exiftool,
can be used to write as well. So we either name everything which calls a
backend to work with info, reading or writing, in the -info- namespace,
or we split read and writing into separate namespaces.

Unless people have a strong opinion either way, I'm going to ask that
reading info be in the -info- namespace and writing in the -tag-
namespace. Which would require you to change emms-tracktag.el and its
various code references to emms-tag-tracktag. This way we could later on
write emms-tag-exiftool.el and others like it, with emms-tag-editor
being the "frontend" to these.

> that being said, there's not much to the integration at this point, it
> could be brought into the emms-tag-editor module, rather than being on
> its own.

It should have its own file.

>> I think that adding ert testing is fine, but I would only add it after
>> the code has stabilized somewhat. Since the unit tests are very short,
>> they can be kept in the same file as the tracktag code for now.
>
> sounds good. i've been trained to write tests at work all the time, so
> its more of a development habit of mine. i do think it makes sense wait
> until this code/feature has stabilized.

The difference is between writing tests and committing them. I think that
they should be committed to the codebase at a later time.

>>> By the way, I used some real metadata from tracks I have, but afaik that
>>> is not copyrighted data. If we'd prefer to keep it out of the code base,
>>> I can replace it.
>>
>> Indeed, we should not have real metadata in the codebase since this is
>> what an automated search 'bot would latch onto and potentially cause
>> trouble.
>
> i just remove the tests from the commit at this point.
>
>> Based on the volume of code you are adding, I would recommend that you
>> open a Savannah account (if you don't have one already) and that I give
>> you write access to the repo. At that point you can do all of your work
>> in a remote branch.
>>
>> In a remote branch you can break anything and everything with impunity,
>> and everyone else can easily grab a copy for testing. We recently did
>> this with Petteri's info-native branch and it worked well.
>
> done! thank you!

Welcome aboard!

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