| Newsgroups |
gmane.comp.audio.eac.user |
| Message-ID |
<[email protected]> |
On 9/29/20 3:56 PM, Fred Maxwell [email protected] [EAC] wrote:
> Not everyone who listens to music is tech savvy. Think of some
> guy deciding that the FLAC field names should all be in his
> native language of Tagalog only to later lose all of his hard
> work at tagging when he tries to convert from FLAC to ALAC, MP3,
> etc. Standards are not supposed to be suggestions. That’s how
> they assure interoperability..
The fact that FLAC allows you to use any tag name you want does /not/
mean that they're aren't a standard set of universally-accepted tag
names that any reasonable player is going to recognize. There's a very
stripped-down starter set listed at
https://xiph.org/vorbis/doc/v-comment.html.
For a bunch of unimportant reasons, I'm primarily a FLAC user and my
standard ARTIST, ALBUM, TITLE, DATE and TRACKNUMBER tags are recognized
by my main music server, by my cell phone, by every Linux FLAC player
I've ever experimented with, by the standalone tagger program I use
under W*nd*ws and by Foobar2000, a very popular player/tagger. Oh, and
also by the commercial radio station playlist software that I
occasionally interact with in my community radio volunteer work.
Any hypothetical Tagalog tagger would /immediately/ find out that
nothing he used to play his files would display the information.
One nice thing about FLAC tagging that many may have little reason to
consider in relation to MP3/ID3 and/or whatever AAC/iTunes uses is that
the tag names are exactly what one would read/say in English. The ones I
listed above are not translated behind the scenes into TPE1 or TXXX
something else equally obscure, they're stored as written and those
plain English words are what players look for. That's probably neither
advantage nor disadvantage to most normal people, but to someone like me
who digitizes a lot of analog material and really wants to document
things like TURNTABLE, TAPEDECK, TRANSFERDATE, CARTRIDGE, etc. it's an
incredible convenience.
> That argues for the ability to add custom tags to FLAC, not for
> FLAC to abandon the notion of a basic, standardized, required set
> of tags.
But FLAC has in no way abandoned that. If, as I sometimes prefer to do,
I input my tags at the command line where I have complete control over
what I enter, my ARTIST entry is what /every/ piece of player software
or hardware I use recognizes and displays as the artist. Ditto TITLE,
ALBUM, etc. There is /zero/ ambiguity or confusion.
Realistically, I suspect that very, very few people—even
technically-minded ones—use |metaflac| at the command line to enter
tags, so for the kind of fundamental “What is this song” stuff we're
talking about here, it's simply not a real-world issue. Given that the
hypothetical Tagalog speaker is apparently also non-technical, I doubt
he's going to be writing scripts to tag his files at the commandline
with his custom Tagalog names. He's probably going to use software that
may present ARTIST to him as ARTISTA in the GUI but behind the scenes
that software is going to write a standard English ARTIST tag.
Most do their tagging in the GUI of their choice and they simply never
have to think about whether a FLAC file is getting an ARTIST tag while
an MP3 gets TPE1 and AAC gets…I don't know what AAC gets, and that's
kinda my point. For most people, it's all abstracted away and they don't
have to care.
Trivia: I mentioned radio station software above. When I first started
trying to organize their library, I lost vast chunks of my mind because
what I would see in the standard tags when logged onto the station was
not the same thing I'd see if I downloaded the file and examined it
locally. Eventually I figured out that the radio software would look at
the ID3 tags when an MP3 was added to the library, copy all the
information over to APE tags, then from that moment forward /only/ ever
read or write APE. Once I figured that out and examined the contents of
the APE tags, I soon realized that it was because that software needed
quite a few custom tags of its own and trying to shoehorn everything
into ID3 would simply have been more trouble than it was worth while
freeform APE would work just fine.
As for file size, this discussion makes me want to track down the
official ALAC encoder for some testing. I'm using some unofficial Linux
thing that creates playable files, but they're definitely larger (though
barely) than FLAC. One thing I noticed many years ago using whatever
encoder was included with dBpoweramp is that ALAC absolutely /sucked/
with mono material in a stereo container compared to FLAC. FLAC was
clearly taking advantage of the identical channels to perform
significantly smarter compression than ALAC. However, the last time I
did any experimentation with that, while FLAC still won, the difference
was nowhere near as dramatic. Nowadays, every player I use is
comfortable with 1-channel files (that didn't used to be the case), so I
just create those where appropriate.