Cannot export this perticular project to flac

Hello everyone,
I’ve been recording for my friends recently while I bump into this issue. It seems that I cannot export this perticular project to FLAC.
Dropbox link: https://www.dropbox.com/s/ivpealxcl4ca8ef/problem.zip?dl=0
Each time I tred “export” “export selected audio”, it would only show “Unable to export” in a message dialogue box without any additional info (see attachments).
The audio can be export to .mp3 or .wav without any problem. So what’s wrong with the FLAC?

OS: Win10 x64 (both, 1 laptop, 1 desktop)
Ver: Audacity 2.2.2 installer
p.s. I’ve recorded some of the tracks on one machine before moved to the other and recorded more tracks/ editing.

Thanks for any advise.
fullwindow000.png

The problem is the metadata. The Flac encoder is choking on your custom tag “作曲家”
If you remove that tag, or change it to “Composer”, then the export should work.

The Flac encoder seems to be happy with any UTF-8 characters as tag “values”, but it doesn’t like multi-byte characters for tag names.
There’s some additional information here: https://en.wikipedia.org/wiki/Vorbis_comment#Format
(Note that the “Field Name” must be printable ASCII characters, but the data is UTF-8)

Hello steve,
THANK YOU VERY MUCH!!!
I’ve check the character compatibility with file, name, track name, even meta-value and it all goes the same. It never occures to me that it’s the field name! Stupid me.
Again, thanks a lot!

I’ve logged this as a bug because I think Audacity should be smart enough to detect non-ASCII characters in the field name and give a helpful warning.

It would be a nice idea! Thank you!

I have written a possible fix for this, but I’m unsure whether it should apply to all formats. Wikipedia clearly states that for Vorbis comments, tag names should be ascii. If anyone can find information about whether this is also true for other formats (particularly WAV, AIFF, AC3 and MP3), please post a link to the information as a reply.

From this document it appears that ascii is required for Dolby AC3: https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf

For disclaimer, I’m not an export of this sort of things, just someone messing with google :smiley:

Here is the document to ID3v2.4, which I believe is the tagging system for MP3
Structure: http://id3.org/id3v2.4.0-structure
Frames:http://id3.org/id3v2.4.0-frames

In section 4.2.6 of the “frames”, it does seem like the “Description” definition accept the encodeing setting of that perticular frame. The text encoding is defined in “4. ID3v2 frame overview” of ID3v2.4 structure, which includes UTF-8/UTF-16

And it works fine with MP3 export in Audacity :stuck_out_tongue:

Seems like WAV do not have a common method for meta-tagging. However, according to wikipedia, WAV and AIFF can support ID3 chunks.

So I suppose it depends on how Audacity stores the metadata when we export the file. According to my experiment(open with mp3tag program) on .WAV, it works fine and saying its encoded with ID3v2.3.

Thanks for the additional information Ewing. This broadly agrees with the information that I found elsewhere.

We certainly want to retain support for multi-byte characters in the tag “data”, as this is widely supported in other formats / applications, and widely used. Most formats explicitly allow this, and I’ve found no cases of this causing a problem in Audacity or other software.

On the other hand, for several formats, tag “names” are explicitly specified as single byte ascii characters, so multi-byte characters are “illegal”. We also know that for at least one format, multi-byte characters in the tag name can cause the encoder to crash. We certainly don’t want Audacity to create “illegal” files that may cause other applications to crash.

While multi-byte characters may be “allowed” in some formats, I have found nothing to say that multi-byte support is “required” for any file type. In fact, the RIFF specification (which includes WAV and AIFF among others) states that applications may legally ignore non-standard tags.

I think the way that we will be fixing this is to disallow multi-byte characters in the tag “name” (the tag will be rejected and an error message written to the Audacity log), but we will retain full UTF-8 support in tag “data”.

I’m wondering, if it’s possible to have a drop down menu for user to select predefined tag “name” field? Or at least for those audio formats that currently use ID3 as metadata container (.mp3, .wav, and .aiff AFAIK).

I encountered the issue in the first place because I’m not sure what tag name option I have. So I decided to give my own one. :stuck_out_tongue:

For ID3 metadata format, seems like most tag name (or “frame description” in their term) you can think of is already predefined . So maybe Audacity can provide different “metadata editor” behaviour when selecting different export format method: If it’s using ID3, provide drop-down menu for those predefined options and maybe also enable custom tag name input (with “TXXX” as fram id); if it’s other formats (e.g. flac), provide only basic tag names and restricting custom tag name input.

But I guess this wouldn’t be a easy fix, and probably depends on how Audacity interacts with audio encoders. Since there’s not much I can do with the coding part, I fully respect all of the programmers and you have my greatest gratitude.

The problem with providing format specific metadata, is that the metadata is stored in the “project” (Edit menu > Metadata). Audacity has no way of knowing what format(s) you will export until you export, so users could waste a great deal of time entering a lot of metadata that is not supported by the format that they eventually decide to export.

Rather than that, the developers decided to provide the basic tags that are supported by most format, plus an option for users to add additional tags. The problem was that a bit too much freedom was given for those custom tags, allowing multi-byte characters in the tag name, which is “illegal” for vorbis comments and in some cases could cause the encoder to crash, taking Audacity down with it. I have narrowed that freedom a little, by not allowing multi-byte characters in the tag name (but still fully supporting UTF-8 in the tag data).