D16579: Musepack disk number field name is DISC.

James Smith noreply at phabricator.kde.org
Thu Nov 1 20:17:08 GMT 2018


smithjd added a comment.


  In D16579#352282 <https://phabricator.kde.org/D16579#352282>, @bruns wrote:
  
  > In D16579#352279 <https://phabricator.kde.org/D16579#352279>, @smithjd wrote:
  >
  > > I would instead recommend a tag editor that properly tags APE files, such as puddletag. APE-using formats are less mainstream than id3 using formats. Users with APE-using formats usually know WHY they use their format of choice, and will know there are potential support shortfalls such as non-compliant tagging software, or software that allows to circumvent the accepted tagging standard, and will know how to mitigate or avoid such issues. I must also point out that stricter tag field adherence is better for APE-using formats in particular, and is better for all tag-using formats in general.
  >
  >
  > Good luck "educating" every APE user, they will really like to be told they should do what you consider right.
  
  
  ...and we should probably rip out *EVERY* other format except for mp3 with its larger installed base and because it's standard fields are more supported by other software.
  
  This is a *fix* for APE tag support, not an argument over why there are *de-facto* standard tag fields or why certain users can screw up with powerful software, or why standardization is a problem and goal, especially in a tag format that permits arbitrary field names. There are 2 sources attached to this review and anecdotal evidence as to what a number of tag programs can or do write into APE tags. This is enough for an educated guess as to a broad consensus on standardized APE field names.
  
  I'm also not in favour of compatibility with alternatives to the de-facto APE field names. We should not be encouraging alternatives to well-established, documented field names. It's also potential burden on the writers of other software and also on the users of APE tags, and detrimental to the APE-using format's ecosystem.

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D16579

To: smithjd, astippich, bruns
Cc: bruns, astippich, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, spoorun, ngraham, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181101/4d1edaa3/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list