硬盘里以前有80+G的APE格式的专辑，每个都带了一个CUE索引文件(播放列表)，后来发现FLAC可以内嵌这个索引(列表)，而且FLAC格式在编码解码上的速度和资源占用，以及容错处理均比APE有很大的优势，遂将硬盘上的APE全部转换为内嵌索引的FLAC格式了。可惜AirPlay现在还不支持FLAC内嵌索引的读取，要放FLAC就只能凭感觉拖进度条了。

目前很少支持内嵌cue的播放器。
虽然精简掉一个cue，不过那文件本身就不到2KB，占不了多少地方。万一需要编辑CUE（转编码、修正别人的错误等），因为内嵌了，也很麻烦。
而且看资料说Flac 嵌入的 Cue （储存在 METADATA_BLOCK_CUESHEET）并不保存 TITLE，PERFORMER 等信息，应该没多少人用。
如果LZ有更多这方面的资料，可以一起研究下看看。

很好有用内嵌的，不方便，有隐患

我现在是用foobar2000放这些内嵌CUE的FLAC，TITLE、PERFORMER这些信息是可以在“其他字段”里手动添加的，而且可以批量修改，改起来也费不了什么事。不过确实的，FLAC默认不保存这些字段，手动添加起来确实费事一些，但也费不了多少时间。
内嵌的目的不是说腾那几KB的空间，是多了一个文件，管理起来不方便，既要文件名对应，又要CUE内部的音频文件名对应什么的。更主要的是FLAC本身在编码上的优势，虽然一张专辑的体积比APE要大20MB左右。

catplus说的隐患是什么呢？个人觉得如果不是直接造成播放器崩溃或者文件损坏，那就没什么可忧虑的。如果是安全方面的，就算给系统带入几个exploit，我想也没什么人会想着利用这个去攻击吧。

按照微软的MSDN的资料，存在利用媒体文件的tag进行攻击的方法。所以微软的是过滤了tag才交给解码器处理的。

此外，有很多修改标签的工具非常不规范，比如foobar，造成其它播放器无法播放，或者崩溃，问题很多。要想完全弄好一个写入tag，要花很大精力才能周全。

何况，如你所说的，flac自己标签并不支持你需要的字段，如果你自己定义的话，别的播放器无法读取，又会带来一堆问题。

最好的方法，目前看就是cue，所有的内置tag的都有很多很多问题。深入开发，就会发现，别说flac，就是mp3 tag都搞死人

确实，采用内嵌CUE的FLAC来放音乐的人不多，但要把自己的作品做成一个精品，吸引更多的用户来使用，和同类软件竞争起来有更多拿得出手的东西，那就应该是在方方面面都要体现出人性化和对用户的体贴，哪怕只是一个操作的说明文字都要力求表述得恰到好处，让用户一看就能最大程度地了解到这个操作用法是怎样的，会带来什么样的效果，而不能说使用内嵌CUE的FLAC的用户不多，那么就斩钉截铁地否决了。你们说是不是呢？

如果这个功能是很容易就能实现的，还请作者辛苦一下，在新版里加入支持吧。在此先谢过了。当然，如果这个小小的功能会耗费巨大的编程时间，跟其能够体现出来的价值相差甚远，那么不加入这个功能也算有理由的，可以理解。

我是搞移动终端嵌入式系统开发的，对PC上的多媒体软件开发完全不了解，也不知说胡话没有，呵呵。

好的播放器，首先就是要遵守标准，否则无法和其它软件交换数据的。不能说这个需求难，关键这个需求可能是非标准的，如果按照标准的话，可能达不到你希望的结果。

另外，开发角度精力有限，主要还是要满足大多数人的主流需要。兼容各种媒体歌词的tag是很浩大的工程，得花很长时间。

刚发了帖才看到有回复了，效率挺高的，赞一个。
“flac自己标签并不支持你需要的字段”我需要的也就只有作者，演奏者，标题，专辑，年代，音轨，风格几个了，什么DISC ID这些我拿来没什么用的。
见了回复，知道是从兼容性上考虑的，我就无话可说了。不能要求太多，不是么？只能希望AirPlay今后能够找到一种比较折中的解决方案来实现我的愿望了。

另：看到你们的征名帖了，我觉得叫“飘乐”还不错的。

好的播放器，首先就是要遵守标准。
为这句再赞一个。就为这个，今后继续支持你们。
我也理解你们开发者的难处，就不讨论这个了。
谢谢以上的回复。

非常感谢理解支持

话说 IE 开发小组宣布重回标准，这是多么惊天地、泣鬼神的好事啊……
话说光 MP3 ID3 标准就至少5个……果然开源容易开出问题么……

不止5个，极其复杂