User Tools

Site Tools


wiki:blog

Handling SACDs

A long time ago, I bought a copy of an SACD of Heifitz playing Bruch's Violin Concerto: for the avoidance of doubt, here's the invoice proving I paid for my copy!

What I hadn't realised, however, is that the disc I brought was an SACD -a high-definition “improvement” on standard CD audio which never really took off and, to this day, requires some fairly unique -and uniquely expensive!- audio gear to interpret and play in all its high-def glory. Lacking said hifi equipment at the time, I merely popped the SACD in a standard CD player and ripped it as usual (SACD, fortunately, was backwardly-compatible with standard CD and could thus be played -at ordinary CD audio quality- on regular CD equipment).

Due to a recent file system mishap (i.e., I clicked 'delete' when I meant to click 'rename'!), I needed to re-rip that particular SACD the other day, but discovered that storing it in the loft in Australia during several inland Summers had done terrible things to it: the thing was practically unplayable. I therefore did what I do not ordinarily make a habit of: I downloaded someone else's rip of the same disc, courtesy of a torrent site.

Trouble is, that download came as a single ISO file, not separate tracks:

So, here was my new problem for the day: how do you turn an ISO of an SACD into separate FLAC tracks that you would have obtained by ripping an ordinary CD of the same music?

Well, on Linux, there's a small utility you can install which will do the first part of the job, called sacd_extract. It's not in Arch Linux's standard repositories, but can be installed from the AUR. Other distros will have similar workarounds to installing the tool.

Once the tool is installed, you can then simply issue this command:

sacd_extract -2 -s -C -i name-of.iso

That pulls individual tracks 'out' of the ISO, creating separate files for each -though the files will be in “DSF” format, which is the extension used to identify high-resolution 'delta sigma' modulated audio files. Note, by the way, that the “-2” in the above command has already stripped out a lot of data contained within the source ISO: it's an instruction to turn the multi-channel audio contained in the original SACD into 2-channel, ordinary stereo, audio files. Working on my specific SACD ISO file, the process looked like this:

[[email protected] Bruch]$ sacd_extract -2 -s -C -i Bruch\ Violin\ Concerto\ No.\ 1.iso 
Exporting CUE sheet [Jascha Heifetz - Bruch Violin Concerto No. 1.cue]
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf] (1/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf] (2/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf] (3/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/04 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Introduction Grave; Adagio cantabile.dsf] (4/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/05 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Allegro.dsf] (5/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/06 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Adagio; Andante sostenuto.dsf] (6/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/07 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Finale Allegro guerriero.dsf] (7/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/08 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro non troppo.dsf] (8/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf] (9/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/10 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro con fuoco.dsf] (10/10)..
Completed: 100% (19.1MB), Total: 100% (19.1MB) at 11.08MB/sec

That resulted in component tracks being extracted into a sub-directory, whose contents ended up looking like this:

[[email protected] Jascha Heifetz - Bruch Violin Concerto No. 1]$ ls -sh
total 2.6G
311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'
317M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
269M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf'
315M '04 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Introduction Grave; Adagio cantabile.dsf'
187M '05 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Allegro.dsf'
266M '06 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Adagio; Andante sostenuto.dsf'
276M '07 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Finale Allegro guerriero.dsf'
507M '08 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro non troppo.dsf'
146M '09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
 47M '10 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro con fuoco.dsf'

You will note that all these files are of type “.dsf”. You will also note that they are all enormous in size! Bear in mind, an ordinary CD would contain around 650MB of data: here, we have over 2.6GB of the stuff!

So, given that I'm over 17 and my ears cannot, accordingly, tell the difference between the high-res, deep bit-depth audio recording that is a DSF and ye olde FLAC equivalent; and given that I don't have an infinitely-sized hard disk in which to store around 2GB of un-needed, un-wanted data… how do you go about converting DSF files into 'ordinary' FLAC ones?

Well, there are various ways of doing that, depending on what software you want to use. But since it's highly likely you already have ffmpeg installed, here's one way of doing it:

for f in *.dsf; do ffmpeg -i "$f" -ar 44100 -sample_fmt s16 "${f%%.dsf}.flac"; done

That loops through all the DSFs found in a directory (which are likely to be using a 96KHz sampling rate) and down-samples each of them in turn to a FLAC file that uses a 44.1KHz sampling rate (which is the same rate ordinary CDs use). It also switches to using only 16 bits to record each sample (rather than the 24 bits per sample that the high-def DSF original probably uses). A 16-bit depth is, again, what an ordinary CD uses. Doing that on my Heifetz tracks created earlier, I see output such as this:

Output #0, flac, to '09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.flac':
  Metadata:
    title           : Adagio
    artist          : Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New Symphony Orchestra of London
    album           : Bruch: Violin Concerto No. 1; Scottish Fantasy & Vieuxtemps: Violin Concerto No. 5
    genre           : Classical
    TRACKNUMBER     : 9
    date            : 2005-01-11
    encoder         : Lavf58.20.100
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16, 128 kb/s
    Metadata:
      encoder         : Lavc58.35.100 flac
size=   16176kB time=00:03:36.30 bitrate= 612.6kbits/s speed=89.2x    
video:0kB audio:16168kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.051644%
ffmpeg version n4.1.3 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20181127
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
[dsf @ 0x55bd81a83d80] Estimating duration from bitrate, this may be inaccurate

The final 'this may be inaccurate' warning can be safely ignored. Otherwise, this sort of output appears once-per-track undergoing conversion… but at the end of the process, you have essentially converted an SACD rip into an ordinary CD rip. This means you are losing data from the original… but it's data your ears probably can't hear anyway!

In practical terms, you will save a lot of disk space. Here again, for example, are the file sizes of a few 'source' DSFs:

ls -sh *.dsf
  311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'
  317M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
  269M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf'

And here are their FLAC-converted equivalents:

ls -sh *.flac
  36M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.flac'
  34M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.flac'
  34M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.flac'

You will note that you are getting file size reductions of 311M to 36M (to take one example): a reduction of around 88%. But the resulting FLAC is a faithful representation of what you would have ripped from an ordinary CD, so still (in my view!) is a properly lossless audio file.

As a further illustration. Here's an original DSF:

311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'

Here is the down-sampled FLAC equivalent:

36M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.flac'

And here's a 192kbps MP3 I converted from the FLAC:

11M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.mp3'

Since the MP3 is still 75% smaller than the FLAC, there's clearly a lot of audio signal that can be compressed (and -mostly inaudibly!- removed) from the FLAC file, despite the FLAC file itself having lost around 88% of the original DSF signal data. That's my way, at least, of reassuring myself that the conversion from DSF to FLAC hasn't lost anything to care about.

Now the sort of audiophiles that haunt the likes of the Hydrogenaudio forums would have a fainting fit at what I've just described! They get very upset at reducing bit-depth from 24 to 16, for example; and proxy wars have been fought over whether human ears can hear the difference between 44.1KHz and 88.2KHz (or higher) sampling rates or 16-bit and 24-bit depth. But I'm a musicphile, not an audiophile: provided my music sounds great, and I know I've not lost anything I could plausibly hear, I don't mind down-converting SACD to CDs for my own listening purposes. Your mileage is free to vary, of course!

2019/07/06 09:56 · dizwell

Dogfooding

I was fortunate this month to be allowed to buy around 50 music CDs (for very little, which was why it was allowed in the first place!). All had to be ripped, of course: using the Classical CD Ripper (CCDR) for any length of time made me realise that my original version needed to be improved -and that's why I wrote about the new Version 2 of CCDR last time.

Now, I'd originally written CCDR with the idea that it would get all the 'album-y' stuff about a CD's metadata right, but that you would sort out the 'track-y' stuff later on with a separate tool, such as Easytag or Puddletag. That seemed like a reasonable move, since CCDR is concerned with ripping CDs, not one-at-a-time tracks.

When I got a bit fed up of having to launch Easytag or Puddletag separately after each rip, however, I soon felt the need for a command-line tag utility to get these 'track-y' bits of metadata correct, too: thus was born the Classical CD Tagger, or CCDT.

From the outset, then: CCDR got most of the tag data for an 'album' correct; CCDT only had to fill in the bits that CCDR didn't bother setting. It therefore really only tagged track titles and not a lot else. I hadn't envisaged CDs being ripped by non-CCDR tools and then needing to have all their metadata fixed by a command-line tag tool. But guess what happens when, confronted with a pile of 50 CDs to rip, you ask your other half to help out… an other half who is firmly wedded to Windows-only tools! You do, then, indeed end up with a pile of hundreds of tracks, all of which need to be tagged properly from scratch. The old assumption that CCDR would have got most of the tags right beforehand proves, in those circumstances, completely wrong!

Thus, by virtue of having to use this stuff at length, at home, I decided that the Classical CD Tagger needed a Version 2 re-write, too: it needed to be able to supply all the tags for a digital music file, not just the ones you thought CCDR wouldn't have supplied already. It also needed to incorporate the Dizwell Tag Cleaner (DTC) functionality, since I found that invoking that third utility every time I'd finished tagging a CD (or a part of a CD) was rapidly getting tedious!

So the short version of this blog post is that Version 2 of the CCDT is now available for download from the usual place.

It is extensively re-worked so that it now uses colour effectively for prompts, warnings and user input, keeping each class of information clearly separate. It allows you to supply album-wide as well as track-specific tagging information. It auto-numbers tracks if asked, starting from any given number and incrementing from that point onwards. It will display the tag metadata provided for the first FLAC file found. It will apply the Dizwell Tag Cleaner functionality to a set of FLACs if asked. It will also remember the tags you supplied last time you ran the utility (so, if you are tagging, say, Beethoven's 5th and 6th symphonies, both performed by the Chicago Symphony Orchestra conducted by Lenny Bernstein, you type all that information for Symphony No. 5, but when you come to tag Symphony No. 6, all those details will be available by simply pressing [Enter], as they will have been remembered from the earlier symphony tagging session).

When you press 'q' (and [Enter]) to quit the utility, the program will perform a background clean of the tags associated with all the FLACs in a directory, as if you'd invoked the DTC utility. So at the end of each tagging session, you are guaranteed to end up with a minimal, clean set of effective metadata tags, free of extraneous tags that we have no use for. The DTC check also re-computes MD5 hash values for the musical content of each track, so if you get through without any warning messages appearing (in bright red!), you can be sure that your audio data is in good order internally and is therefore free of corruption or bit-rot problems.

DTC remains available as a separate utility, of course, since you may well want to clean your tags (and check your files for corruption) without actually editing the tag data.

Upgrading from an earlier version is easy: just delete the old ccdt.sh file, wherever you stored it, and copy the new one down on top of it. Chmod +X the new file to make it executable; job done!

2019/06/23 14:47 · dizwell

Classical CD Ripper - Version 2

I have had a bit of re-think about my Classical CD Ripper and accordingly re-worked bits of it to look better, work slightly differently, produce cleaner tags and generally behave more as I wanted it to! As you can see from the screenshot at the left, we're now up to version 2 and I've mastered (?!) the art of ANSI escape sequences to set and unset colours, so it's easier to distinguish between when you're being asked for something, when you're being told something, or when you're being warned that something horrible and erroneous has occurred. :-)

The main, substantial change in Version 2 is that we no longer populate the Album Artist or Original Artist tag (because that's a silly thing to do in the context of classical music); we do, however, now populate the Artist and Composer tags properly. We also physically locate the ripped tracks properly, within a directory hierarchy that uses the conductor or other principal artist's surname as a distinguishing characteristic (thus, you get War Requiem (Britten) and War Requiem (Gardiner)). The other significant changes are cosmetic: as I mentioned, a touch of colour; a general observance of proper indentation and so on.

If you wanted it in just a handful of words: CCDR now obeys the house rules on proper tagging practice!

The thing is still a Bash script (so you can check what it does and change it if it doesn't suit!), and is still readily downloaded from this site at zero cost.

2019/06/11 15:55 · dizwell

Play music with DeaDBeeF

DeadBeef (I'll cope with two capital letters, but I absolutely refuse to use all four!) is a music player and manager for Linux, written in C -so it's light on resources and blindingly fast. It also does pretty much everything I need a music organiser/player to do, very flexibly and capably. The icing on the cake is that it uses the sort of formatting and customisation language that Foobar2000 does on Windows.

The short version is, therefore, that DeadBeef is, just about, the nearest thing to Foobar2000 that Linux has… which makes it rather special, highly desirable and a delight to use.

The one problem it has, which it kind of inherits from the Foobar2000 of yesteryear, is that it is pretty hopeless straight out of the box but can soon be knocked into excellent shape by a judicious bit of customisation. I have accordingly put together a short article explaining how you might go about doing that.

As a long-term KDE user, I've been using Clementine as my main music manager and player -though recently switched to Strawberry, a fork of Clementine, on the grounds that Clementine development seems to have stalled recently. But DeadBeef is now my primary classical music player -and one I wholeheartedly recommend to anyone with a large music collection that needs managing and controlling well.

2019/06/03 16:01 · dizwell

What is the ONLY correct way to tag FLAC audio files?

I recently had an email correspondent question my frequent assertions that ID3 tags should not be present in FLAC files and that the only “proper” way to tag FLACs is with Vorbis Comments. It was a good-natured discussion and I thought I should write it up in a bit more detail.

A bit of History

First things first, then: there are two basic 'tagging schemes' available to anyone trying to markup their audio files with metadata: ID3 tags and Vorbis Comments.

ID3 version 1 (ID3v1) was invented around 1996 by Eric Kemp. It was very restrictive: all tags were stored at the end of the music file in just 128 bytes, with title, artist, album and comments having to fit into just 30 bytes each. Note that the tag names were given: you had no flexibility about what they were called, only what data you stored in each one. Accordingly, hardly anyone ever uses ID3v1 tags these days.

ID3v2 really has nothing to do with ID3v1, was invented in 1998 and allows for variable-sized data up to a whopping 256MB (megabytes!), which starts at the beginning of the music. There is a long list of “accepted” ID3 tag names, so you can't just store data in arbitrarily-named fields. If you wanted to store “bar number where key first modulates”, for example, there's no such tag in ID3 land! (But you'd be certifiable if you wanted to store that sort of data in the first place, so the loss is not -usually- a show-stopper!).

Both ID3 formats were thus invented around the time that MP3 was becoming a favourite audio format, thanks to its small size (and the poor modem speeds of the era which made small music files highly desirable). ID3 is therefore highly associated with MP3 files, though not exclusively, as I'll demonstrate shortly.

Vorbis Comments were invented around 2005 or so by the xiph.org development community, who were busy at that time inventing the open source Ogg Vorbis audio format. Hence the use of the name 'vorbis'. It just happens that xiph.org also invented the FLAC audio format; they naturally used the same tagging format that they'd invented for Ogg files when wondering how to tag FLAC files. A Vorbis tag is a list of fields in the field-name/data format; field names are case-insensitive and you can have up to 4 billion fields at a time (though most software won't read or wrote that many!). Any tag name is permitted and there's no specific format for the data stored in the tag; that said, certain 'standard' tags have become established (such as TITLE, TRACKNUMBER and so on, so that software can be written expecting certain bits of data to be found in certain places). But if you were really desperate to create a tag for “Bar number where first modulation occurs”, Vorbis Comments lets you do that.

So that's a bit of history: the story basically boils down to ID3 being associated with MP3s and Vorbis Comments with FLACs, largely because of the timing of their respective developments: ID3 were invented when fast Internet connections were rare and thus music downloads were generally of the smaller MP3 type; Vorbis Comments were invented at around the same time as FLAC, which began to be more useful as faster Internet speeds made sharing multi-Megabyte-sized files more feasible.

But it's not that simple: FLAC files can store ID3 tags!

A Worked Example

To take a simple example. Here I have a single FLAC track:

[[email protected] ~]$ cd Music/Symphony/
[[email protected] Symphony]$ ls
track01.flac

I can check if it has any Vorbis Comments in it:

[email protected] Symphony]$ metaflac --list track01.flac 
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 69 bytes
  maximum framesize: 8801 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 20844600
  MD5 signature: 1f06351acf4bac40cd153e5b4f07f5be
METADATA block #1
  type: 1 (PADDING)
  is last: true
  length: 25603

There are no Artist, Album, Track or similar-looking tags there!

I can also check that the file has no ID3 tags in it at all:

[[email protected] Symphony]$ id3v2 -l track01.flac 
track01.flac: No ID3 tag

(The 'id3v2' application needs to be installed for these examples to work, of course, as does 'metaflac', which is part of the 'flac' package. Both id3v2 and flac are commonly available in most distro's standard respositories).

In other words, this particular track01.flac is a clean slate, something we can also prove by looking at it in Easytag:

Look at the totally blank set of fields over on the right-hand side of the screen: not a jot of metadata in any of them!

Now let me add an ID3 tag to this file, even though it's a FLAC file. I shall achieve this feat by using the id3v2 program once more, this time with the -A switch, which means “set the Album name tag”:

[[email protected] Symphony]$ id3v2 -A "Symphony1" track01.flac

And let's check that:

[[email protected] Symphony]$ id3v2 -l track01.flac 
id3v1 tag info for track01.flac:
Title  :                                 Artist:                               
Album  : Symphony1                       Year:     , Genre: Unknown (255)
Comment:                                 Track: 0
id3v2 tag info for track01.flac:
TALB (Album/Movie/Show title): Symphony1

So the ID3v2 tag is definitely there, but we are still Vorbis Comment-less:

[[email protected] Symphony]$ metaflac --list track01.flac 
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 69 bytes
  maximum framesize: 8801 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 20844600
  MD5 signature: 1f06351acf4bac40cd153e5b4f07f5be
METADATA block #1
  type: 1 (PADDING)
  is last: true
  length: 25603

…with metaflac's output being no different from before. And, as before, we can check what our command-line addition of an ID3 tag to a FLAC file looks like in Easytag:

Note that Easytag is showing “Symphony1” in the Album field over on the right-hand side of its display: though it's a FLAC file, Easytag has no problem displaying an ID3 tag for it, if it's been put there by some other program.

Now let me add a Vorbis Comment to this same file, whilst doing nothing with the ID3 tag:

metaflac --set-tag=Artist=Beethoven track01.flac

Check with ID3:

[[email protected] Symphony]$ id3v2 -l track01.flac
id3v1 tag info for track01.flac:
Title  :                                 Artist:                               
Album  : Symphony1                       Year:     , Genre: Unknown (255)
Comment:                                 Track: 0
id3v2 tag info for track01.flac:
TALB (Album/Movie/Show title): Symphony1

Note that ID3 still knows this is Symphony1 but has no concept of who the Artist is. Back in metaflac, we see:

[[email protected] Symphony]$ metaflac --list track01.flac 
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 69 bytes
  maximum framesize: 8801 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 20844600
  MD5 signature: 1f06351acf4bac40cd153e5b4f07f5be
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 60
  vendor string: reference libFLAC 1.3.2 20170101
  comments: 1
    comment[0]: Artist=Beethoven
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 25539

So, Vorbis Comments show the Artist is Beethoven, but has no idea what the piece is. From this, we can tell that whilst ID3 tags can co-exist with Vorbis ones, it's not a good idea to mix them in the one file, because each will only tell you part of the picture, and there's no way to synchronise them -so ID3 might tell you this is a work by Beethoven whilst Vorbis insists it's actually by Mozart.

What does Easytag show of this confusing state? This:

Hmm: this is where it gets interesting. Easytag is now displaying the Artist as Beethoven, in the 'Common' area of its tag display, but it's now stopped showing that the Album is “Symphony1”. Incidentally, if you think I'm not displaying the Vorbis Comments, because there's a heading there saying “FLAC Vorbis Tag” and I'm only showing the contents of the 'Common' area… well, you can click on those 'Flac Vorbis Tag' words all you want and it won't change the display or show you anything different at all. Only the 'Common' area is actually usable.

Putting it bluntly, confronted with a FLAC file containing both ID3 and Vorbis tags, Easytag ignores the ID3 tags completely (even though we can prove they are still contained within the audio file itself) and only displays the Vorbis tag contents.

So, if I were to add a piece of text to the “Copyright” field in Easytag, do you think that will be stored as a Vorbis tag or as an ID3 one, or maybe as both? There's only one way to find out. Here's me saving some text in that field in Easytag:

…the file name has gone bold, because the contents of the file have been changed. If I then click the 'Save' option, the tag will be written into the file… but in what format? Let's see:

[[email protected] Symphony]$ metaflac --list track01.flac 
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 69 bytes
  maximum framesize: 8801 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 20844600
  MD5 signature: 1f06351acf4bac40cd153e5b4f07f5be
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 92
  vendor string: reference libFLAC 1.3.2 20170101
  comments: 2
    comment[0]: ARTIST=Beethoven
    comment[1]: COPYRIGHT=2019 Howard Rogers
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 25507

So the new COPYRIGHT tag is there as a Vorbis Comment, along with the previous ARTIST tag added with metaflac as a Vorbis Comment. But has it been saved as an ID3 tag as well, perhaps?

[[email protected] Symphony]$ id3v2 -l track01.flac 
track01.flac: No ID3 tag

Wow! Without any warning, getting Easytag to write tags to a FLAC file has completely erased the ID3v2 tag we previously put there!

What do we conclude from this short trip through tagland? Well:

  1. It is possible to store ID3 tags in FLAC files;
  2. But a lot of GUI software will expect FLAC files to store Vorbis tags;
  3. And will write only Vorbis tags when saving to FLAC files;
  4. And will, moreover, erase any ID3 tags that were somehow previously stored in the FLAC file.

Most tagging software you will meet, therefore, expects FLAC and Vorbis Comments to go hand-in-hand, to the point where if a combination of tag types is found within a FLAC file, most tagging software will ignore (at best) or erase (at worst) the ID3 tags and their associated data… without asking permission or giving any form of warning.

It is for this reason that I strongly assert that you must use Vorbis Comments when tagging FLAC files and using ID3 tags with them is just wrong. It's not that it's impossible to use ID3 with FLACs, but you will be skating on thin ice if you do: one day, your carefully-crafted data stored in the 'wrong' sort of tag will be simply erased by the software you use, no questions asked nor apologies offered!

Another Worked Example

Now, if I'm using a more KDE-based distro, I'll tend to use Puddletag as my GUI tagger rather than Easytag. Does that behave any differently? Well, let's start off with a clean-slate FLAC file once more, add an ID3v2 tag to it and see what Puddletag makes of a FLAC file containing an ID3v2 tag:

Here, the situation is -if anything- even worse than before! When Easytag found an ID3 tag in a FLAC file, it at least displayed it (before eventually erasing it!). But here, though the id3v2 program for sure knows there's an Album tag in the file, Puddletag declares there is no metadata in the file at all!

But if I use Puddletag to set 'Beethoven' as the artist… id3v2 knows nothing about it:

Here you see Puddletag has “Beethoven” showing in the “Artist” field over on the right-hand side of the screen, but a fresh listing of tags in id3v2 in the terminal session displays… only the Album name as before.

Meanwhile, as you might expect by now, metaflac knows the Artist (a Vorbis tag written by Puddletag), but not the Album (an ID3 one, put there earlier by id3v2):

So, once again, although I'm now using a totally different tag editor than before, we have the same situation as before: Puddletag knows, just as Easytag did, that if it's writing to a FLAC file, it must save to Vorbis Comments tags.

Fine… But just to completely mess your head up, now that I've saved the Vorbis comment “Artist”, what's happened to my original ID3 tag “Album”? Let's just see:

Now there's quite a lot going on in that screenshot. The terminal window displays the metaflac output as before: it knows that artist=Beethoven, but nothing else. But then I run id3v2 and prove that Album=Symphony1, as previously set by id3v2 itself. In other words, we see that the file contains both sorts of tags simultaneously… and therefore my previous saving of the file in Puddletag did NOT silently erase the ID3v2 tags, as it did in Easytag.

Meanwhile, Puddletag itself remains convinced that there's an Artist tag, but no Album one.

If anything, this is even more confusing than Easytag (and is the reason I think I'd choose to use Easytag over Puddletag if I had the choice): Easytag at least makes everything consistently Vorbis Comments, albeit by the rather drastic expedient of silently deleting ID3 tags from FLAC files; Puddletag, however, displays only Vorbis Comments, but is quite happy to leave ID3v2 tags sitting there in the background whilst it's at it.

Ugh.

I come back to my original point with my email correspondent: stick to using Vorbis Comments for FLACs, because they are the only tags which both Easytag and Puddletag will display when working with FLAC files. And on the other side of the coin, definitely avoid using ID3v2 tags when working with FLACs, because one program will wipe them without warning and the other will simply ignore them without tell you!

So now you know!

2019/05/30 16:25 · dizwell

Older entries >>

wiki/blog.txt · Last modified: 2018/12/12 14:06 by dizwell