Grant Shoshin Shangreaux <[email protected]> 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"
