confusing handling for multiple releases
Brought to you by:
adhawkins
Menu
▾
▴
#5 confusing handling for multiple releases
Handling for multiple releases attached to the same TOC is very confusing. Running the application in non-interactive (i.e. batch) mode on a collection for roughly half of the albums I received the following messages:
<filename>: Multiple albums found <filename>: No matching album ID found, aborting
This behavior signficantly impairs usabilty, especially since most users would need to investigate independently the cause of the error in order to make the application work on the whole collection.
I have yet to understand how I would use the application for these files.
So far, I have accumulated the following observations:
-
"Multiple albums found" refers to the association of multiple releases of discs of matching table of contents. Such a situation often arises when the same musical content is sold in various countries.
-
Whereas the prior message provides some accurate information, the latter message is confusing, especially if not noticed as occurring for the same album as the prior message.
-
Release notes for version 11.7 include the following remark:
Removed --force-multi option from command line. Now compare stored MUSICBRAINZ_ALBUMID if multiple releases are returned.
The documentation, however, makes no mention of MUSICBRAINZ_ALBUMID nor explains the handling of the case of multiple releases. New users can make no useful deduction from this comment alone.
-
When the same cases are handled in interactive mode, the data displayed interactively expresses no difference between the multiple releases. Both appear identical, leaving the user no practical means to make the preferred choice.
Perhaps some of these observations might be addressed through revision in software or documentation.
Meanwhile, I appreciate any practical advice for using the application to handle the difficult cases.
Hi,
Essentially, you need to run in interactive mode, and choose one of the offered releases, writing its tags to the file.
The MusicBrainz Album ID is listed in the tags to be written if you copy it to the bottom window, along with all of the other tags for that release on MusicBrainz. You need to examine these tags (which will include things like barcode etc.) to determine which of the offered releases matches the one you actually own.
Once these tags have been written, future 'batch' sessions will automatically choose the correct MusicBrainz release based on the MusicBrainz Album ID written to the file's tags.
Appreciate that this could be documented better, hope the above helps.
Andy
I understand your response. A number of small issues come to mind, in case you are considering further enhancements at some time.
Consider the following:
Despite the small points, the application generally works well
Last edit: brainchild 2021-06-07
All good points. At the end of the day, flactag isn't really supposed to be a MusicBrainz data or tag viewer. All of the information is visible on the MusicBrainz web site given the album ID.
Glad you're finding the app useful. It's definitely in need of some updates.
The use case I am considering is attaching a set of basic metadata, needed for selecting an asset from others in a library, to the file that contains the related music. The relevant question is less about viewing the full record from MusicBrainz, and more about having a way to select the best match from a list.
If this use case is important, then it may be useful to consider how feasible it is for a user to make this choice manually, based on the way the interactive interface presently is arranged.
Anyway, I had an unrelated question. I notice that
flactagputs track information under tag names ending with the decimal representation of the track number, surrounded by square brackets. This representation seems like a sensible one, but also one unfamiliar to me. Are you aware of its being employed elsewhere, or had it been invented exclusively forflactag?What extra information do you think is necessary to be able to make the decision as to which release to choose? The interactive interface for flactag is quite 'busy', so I tried to keep the information in there to the minimum.
Regarding the formatting of track information, this scheme is (I believe) fairly standard. The music server I use (Logitech Media Server) uses this scheme, and it's what flactag's scheme was based on. It certainly wasn't something I invented myself.
Well, the straightforward answer, though it may seem evasive, is that given a choice between two data sets, the minimum necessary information for resolving the choice is at least some of the differences. At the moment, the application displays a static set of fields for each option, such that, in many cases, all fields are identical across the multiple matching releases. A truly complete solution would allow the user to explore the differences. Although such a solution may be more complicated, for both the developer and the user, than desired in this application, a plainer solution is available too, that being adding to the static list of fields a few additional items, the fields that are typically different across releases. These fields include country information, label, catalog number, and barcode number.
With respect to track tagging, do you know whether the convention utilized by Logitech Media Server (i.e. Slim Server) is explained in any documentation or other references? The Slim Devices Wiki features a page on tagging conventions, but makes no mention of any scheme for including track information in a whole-disc file. It may be no one has bothered to make this information available formally, but I certainly would be interested in learning about any references you may have used or otherwise discovered.
Last edit: brainchild 2021-06-19
That's a fair point about adding additional information like barcode etc. I'll consider that. I keep saying I'll get back to flactag to make some much needed additions, but never seem to find the time.
Regarding the tagging, I think I asked on the forums all those years ago, and that's the advice I was given.
At the moment,
flactagseems to be the only utility that reads TOC or cue data, computes a MusicBrainz Disc ID, fetches releases data, and applies them to an audio file that captures a full disc.MusicBrainz has developed its own tagging tool, Picard, which is tightly integrated with the design of the service, but the only current support in the project for whole-disc files so far has been as a vaguely-specified item on a long list of possible future features.
I have casually tested the tags generated by
flactagwith some players and other tools that read tag data, and have not experienced solid integration. It appears to me that conventions for tagging single-track files have reached a level of stability that tends to sustain solid interoperability among applications, but not so for track data within files representing whole discs.Meanwhile, the particular convention implemented by
flactagseems to represent the most sensible style of any I have seen. In other cases, I have seen the decimal track representations appended to the alphabetic label name without any brackets, and I would not choose this style in preference to the brackets. FLAC support for embedded cue sheets deliberately omits textual metadata, as the design orientation views this data as auxiliary, and best separated from the capture of track layout and audio data presented on a basic audio CD. Some applications work around this limitation by embedding a cue sheet containing text as a tag value. This solution has serious drawbacks, and a canonical scheme for augmented an embedded cue sheet with separate textual data, as tags, for track-specific information, is badly needed.I have been considering trying to raise a discussion in the MusicBrainz forum about the best way that MusicBrainz might endorse a particular convention on this subject, which other applications might follow, and which might eventually see support in Picard. To such ends, any references, especially concrete documentation, available on the subject, to argue the rationale for the specific convention, or to specify any fine details, would be a valuable resource.
Hi,
I had had some success with other software players using the scheme that Flactag uses. I think that foobar works, although I wouldn't be 100% sure.
As far as documentation goes, I think I got that scheme through a discussion on the LMS forums. It might be worth a search on there to see if you can find any of the posts I made and their responses. My username is 'adhawkins' on there. I had a quick look and couldn't see it, but I didn't spend that much time on it I'm afraid.
I searched the forum for posts made using your handle, and found a good number of hits, but noticed none that address this particular topic. I did find your announcements of the release of the software. Do you suppose the earlier discussions may have been lost in some system-wide event, such as migration to new forum software? Otherwise, do you think you might misremember the forum in which you discussed the specific topic, since you obviously have given the LMS forum quite a bit of contributions? I know I make memory errors of this kind quite a bit, and fifteen years or so is more than enough time for recollection to become hazy.
In any case, thanks for sharing the information you have available at the moment. If you care to scratch together a brief description of the scheme you are using, which you have found successful with some other software, then it might be helpful. At some point I hope to introduce a related discussion into the MusicBrainz forum, with the hope of some system being resolved by that group. such as to help steer the entire community in a more clear and unified course than has been recent experience with handling of whole-disc files.
Meanwhile, I thought of another feature that might be helpful in
flactag. I have a large collection of rips for which I have recorded the catalog and barcode numbers (in a separate spreadsheet). It would be very expedient if I could pass this data to the application along with the audio file, such that the application automatically applied the appropriate tags based on a query that resolved the release matching not only the TOC identifier (which often returns multiple results, as discussed earlier), but also the additional data, fields for disambiguation.It's possible that there was a migration of forum software when the Slimdevices brand was taken over by Logitech many years ago. I'm afraid it's a long time ago so I can't really remember! I've just done a quick search for all my posts, and it looks like I announced flactag in 2006. My memory is that I got the tag format from the forums around that time, but the search doesn't seem to be finding it.
I did find some similar discussion here, which recommends the scheme I'm using:
https://forums.slimdevices.com/showthread.php?9184-FLAC-Cue-Sheet-Support&p=23555&viewfull=1#post23555
Your idea for an enhancement sounds potentially useful. There'd have to be some sort of standard file structure for associating the file names with the barcode or other information. Coming to a workable solution on that could be tricky.
If you wanted a format for representing the associations between file names and metadata, then it would be a cumbersome addition to the application. For single-album invocations of the application, the need is removed to associate various metadata with particular files in the input format.
An easier way may be available, however, even for the bulk case. It is unlikely that all available values for barcode or another field in a collection intersect with multiple possible values for any file. Thus, in each case, the application need only choose the single value in the intersection, if any. The user does not need to associate each input value with a distinct album file. That is, the user may provide a list of files, and for example, a list of barcodes, and then, applying the responses from the network service, the application could resolve which barcode is associated with which file.