Chapter Marks for Opus, Vorbis and FLAC Options

[gholzmann]

Hallo!

For those who might be interested, there exists now a new chapter extension for Vorbis Comments:
http://wiki.xiph.org/Chapter_Extension

This enables chapter marks for all file formats, which use the vorbis comments metadata system:
Opus, Oggg vorbis, flac, speex, etc.

Maybe there are some player developers here - it's a great alternative to chapters in MP4/M4A files and there are more and more people using Vorbis Chapters (especially in the german speaking podcasting scene).

The format is very simple:

CHAPTER001=00:00:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000
CHAPTER002NAME=Chapter 2
CHAPTER003=00:07:35.500
CHAPTER002NAME=Chapter 3
...

Thanks for your attention
LG
Georg

This post has been edited by gholzmann: Oct 19 2012, 17:47

[skamp]

Thanks for the heads up. This should be useful with single file rips, though I'm not sure it's possible to convert CD frames to milliseconds exactly.

[gholzmann]

Thanks for the heads up. This should be useful with single file rips, though I'm not sure it's possible to convert CD frames to milliseconds exactly.

Well, you can of course just skip the milliseconds, if you don't have this information ...

[Kohlrabi]

Thanks for the heads up. This should be useful with single file rips, though I'm not sure it's possible to convert CD frames to milliseconds exactly.

One Audio CD frame contains 588 16bit stereo samples. This leads to one frame being 1/75s = 0.0133s = 13.3ms long. So the chapters can not be mapped 100% accurately to audio CD frames, though I guess sub-ms precision is not really necessary.

This post has been edited by Kohlrabi: Oct 20 2012, 11:34

[Antonski]

Great!
Is it (planned to be) supported by Foobar?
I've added some chapters by Mp3tag, they are visible in FB as tags, but not recognized as chapters (using v1.1.4)
I guess it will be the first one to support it, anyway.

[gholzmann]

Great!
Is it (planned to be) supported by Foobar?

I don't know - VLC should support it in next version:
https://trac.videolan.org/vlc/ticket/6895
(see last comment)

Maybe someone can open a feature request in foobar?

[Anakunda]

Isn't chaptering on OGG files already supprted (atleast with foobar2000)?
Convert any album with multiple tracks to multi-track Vorbis or any Ogg-based format. You get one chaptered file.

This post has been edited by Anakunda: Oct 22 2012, 12:45

[gholzmann]

Isn't chaptering on OGG files already supprted (atleast with foobar2000)?
Convert any album with multiple tracks to multi-track Vorbis or any Ogg-based format. You get one chaptered file.

This was just a hack, where each chapter must be one ogg vorbis file and then they are concatenated in one big file.
That's no real solution, has many other problems and nobody besides some version of foobar supports it ...

For a more in-depth discussion see also:
http://comments.gmane.org/gmane.comp.multi...rbis.devel/5612

[Canar]

This was just a hack

Bullshit. Monty himself, according to the link you gave, claims that chained ogg is a "clean solution". It's a great solution, IMO. Metadata is embedded in the stream. Although it requires a stream-crawl to get the metadata and location info, it is exactly identical to eg. a radio stream with changing metadata.

[rgtb]

Awesome new feature--thanks for the info.

I was getting my hopes up that FB2K 1.1.16 would support it. Oh well, maybe support arrives with 1.1.17.

[gholzmann]

Maybe someone should make a feature request ...

[kode54]

Delightful, conflicting chapter standards.

Let's see. Chained streams:

• Came first.
• Supports multiple formats in the same stream, if you care about that.
• Supports full tagging of each stream.
• Each stream may be an arbitrary number of samples in length, handled by the format.
• Already supported by a number of players, including Winamp and XMPlay. Oh, right, and foobar2000, for many years now.

Chapter tags:

• Newly drafted last March.
• Supports exactly one audio stream, or possibly interleaved audio streams.
• Supports full tagging of just the whole stream, with only titles and web links per chapter, at least until somebody decides to extend the draft again.
• Chapter marks are limited to an arbitrary precision timestamp, with no option for sample accuracy.
• Exactly which players support this, or are likely to support this, but not chained streams? Remember that this format is useless for live streams, as those will likely be transmitting intermittent metadata, which needs to be indicated by stream splices.

Please explain why this idea is better than chained streams again. I would love to know why supporting chained streams requires any more work than supporting this. Remember that seeking already requires bisecting the files to determine the packet offsets and their granule positions. Handling chained streams simply requires this process to take place on file discovery, to determine the offsets of each individual stream. And any player which supports Ogg Vorbis streaming should already support basic chaining, to support streams with metadata.

[rgtb]

chapter tags seem easier to deal with for me (i'm a non-technical user). i record one file, encode it, add metadata (including chapters), and upload it. done. seems more convenient to me than going the chained stream route for which i need to split up files, only to concatenate them again later.

for my typical usage scenario as a consumer of podcasts (i d/l podcasts via a podcatcher and play them back locally), i don't see why i would need the extra functionality of chained streams.

This post has been edited by rgtb: Nov 4 2012, 16:36

[Antonski]

I find this extension very useful for my needs.
I have a god number of albums (mainly progressive rock, concept albums etc) which contains tracks with multiple parts.
If I have to rip/convert an album to a format which doesn't support chapters, I would have two possibilities:
- rip the whole tracks and forget about particular parts, or
- divide the tracks into parts and encode the parts separately.
In the second case I have to tag explicitly the parts so that I know to which 'mother' track they belong, but the naming convention becomes a bit clumsy.
The same goes for many classical albums, BTW.
In order to keep the album structure as close as possible to original, currently I use Musepack, which has a native chapter support. However, adding chapters in mpc files is a bit tricky, because they are part of the stream. The advantage is, that the chapters cannot be removed easily by accident.
However, the suggested ogg chapter extension is easier, because the chapters can be added by a regular tag editor.
So, I could make use of this extension if I decide to use vorbis (for instance) as a lossy codec of choice.

This post has been edited by Antonski: Nov 5 2012, 00:18

[saratoga]

Please explain why this idea is better than chained streams again. I would love to know why supporting chained streams requires any more work than supporting this. Remember that seeking already requires bisecting the files to determine the packet offsets and their granule positions. Handling chained streams simply requires this process to take place on file discovery, to determine the offsets of each individual stream. And any player which supports Ogg Vorbis streaming should already support basic chaining, to support streams with metadata.

For what its worth, we can't support chaining in Rockbox because we have no way to reallocate the various buffer sizes without completely quitting the codec and reallocating everything (since we have no virtual addressing and so cannot defragment the address space). We also have no way to detect that you've chained files since we can't seek to the end of the file because its most likely not loaded from the disk yet. So from our point of view, restrictions on inane things (like changing the transform buffer sizes mid-file with no way to know prior to scanning the entire file) are certainly welcome. We could reasonably support chapter tags though, and we do for other formats.

[gholzmann]

As the others already said, IMHO this chapter extension is much easier to use for tagging software and player developers.

For instance, we usually have 2h-3h podcast files with lots of chapters.
These chapters are often changed, some new ones are added, a few are deleted etc.
With chained chapters I would have to manipulate the direct ogg stream at every change - so I can just change the tags with any tagging software available.

And it's also easy for (simple) player developers: if they just use a library for playing media files, they can just read the chapter tags and seek to the desired location.
Furthermore it's similar to other common chapter mark systems as MP4, ID3 chapters (http://id3.org/id3v2-chapters-1.0), Matroska, WebVTT etc.

However, personally I do not care which exact chapter system should be used. If you think that the chained chapters are more appropriate, please speak up at the vorbis-dev mailing list, they are very open for suggestions!
For me it's just important, that there is one way which most of the devs and users agree on - it's 2012 and not possible to listen to podcasts with chapters in Ogg Vorbis are Opus, this should change!
Chapters are very common in MP4 podcasts and are also getting more and more popular in MP3 (http://id3.org/id3v2-chapters-1.0 - players like instacast or antennapod support it on the iPhone and Android).
Hopefully this will be possible with Ogg Vorbis and Opus too ...