opus - Dec 2016 - [ogg-dev] comment writing in opus / liboggz

On 31 December 2016 at 14:03, Timothy B. Terriberry <tterribe at xiph.org>
wrote:
> Ian Malone wrote:
>>
>> out, due to the Opus pre-seek, I think. Fixing that probably requires
>> adding an Opus-specific metric to liboggz, since the current default
>> linear one doesn't deal with first granule position being set.
Thought
>> I'd check before getting into that whether anyone has looked at
this
>> already?
>
>
> I thought Mark Harris implemented this in
> <https://git.xiph.org/?p=liboggz.git;a=commitdiff;h=0a523700afbb>.
I'm not
> sure there's been a release since then, though. Are you looking at the
> latest git, or is there something wrong with that implementation?
>
Thanks, that does look like the right set of changes, with metrics
handled too. The distro packaged version I've got didn't have it, and
I'd found kfish's github rather than the Xiph git.
>> Another thought, could vorbiscomment do with having Opus comment
support
>> added?
>
>
> Or make an opuscomment for opus-tools. I'm not sure which is the better
> approach, though the latter certainly seems like it would be less
surprising
> for users.
It'd certainly make sense for it to be included with other Opus tools,
vorbiscomment is a bit of an oddity within vorbis-tools since (hazily
recalled) it supports other stream types than just Vorbis (and a
general comment editor is useful, though it sounds like liboggz has
that covered again).

-- 
imalone
http://ibmalone.blogspot.co.uk

Ian Malone wrote:
>>> Another thought, could vorbiscomment do with having Opus comment
support
>>> added?
>>
>>
>> Or make an opuscomment for opus-tools. I'm not sure which is the
better
>> approach, though the latter certainly seems like it would be less
surprising
>> for users.
>
> It'd certainly make sense for it to be included with other Opus tools,
> vorbiscomment is a bit of an oddity within vorbis-tools since (hazily
> recalled) it supports other stream types than just Vorbis (and a
> general comment editor is useful, though it sounds like liboggz has
> that covered again).

What might be most useful is some kind of opusedit or opusutil utility
that can make simple changes to an Opus file.  Although the initial
version might support only adding, removing, or changing comments,
having such a utility could make it easier to support other simple
changes in the future, such as:

 * Add/remove/change attached pictures (album art)
 * Adjust output gain in header
 * Change original sample rate in header
 * Change channel mapping / extract channels
 * Sample-accurate trimming by adjusting pre-skip and end trimming and
removing whole frames
 * Adjust timestamps (granule positions), e.g. to start at time 0
 * Adjust Ogg page durations, to reduce either overhead or streaming delay
 * Repair some broken files
 * Remove any CBR packet padding
 * Add/remove comment/picture padding

Several of these may require re-writing (but not re-encoding) the
whole file, for example if there is not enough padding space for
additional comments or attached pictures.  Even if multiple operations
are performed, the file should be re-written at most once.

Thoughts?

 - Mark

Mark Harris wrote:
>   * Adjust output gain in header
An R128-gain tool is still noticeably missing from the current opus-tools.

On 31 December 2016 at 21:04, Mark Harris <mark.hsj at gmail.com>
wrote:
> Ian Malone wrote:
>>>> Another thought, could vorbiscomment do with having Opus
comment support
>>>> added?
>>>
>>>
>>> Or make an opuscomment for opus-tools. I'm not sure which is
the better
>>> approach, though the latter certainly seems like it would be less
surprising
>>> for users.
>>
>> It'd certainly make sense for it to be included with other Opus
tools,
>> vorbiscomment is a bit of an oddity within vorbis-tools since (hazily
>> recalled) it supports other stream types than just Vorbis (and a
>> general comment editor is useful, though it sounds like liboggz has
>> that covered again).
>
>
> What might be most useful is some kind of opusedit or opusutil utility
> that can make simple changes to an Opus file.  Although the initial
> version might support only adding, removing, or changing comments,
> having such a utility could make it easier to support other simple
> changes in the future, such as:
>
>  * Add/remove/change attached pictures (album art)
>  * Adjust output gain in header
>  * Change original sample rate in header
>  * Change channel mapping / extract channels
>  * Sample-accurate trimming by adjusting pre-skip and end trimming and
> removing whole frames
>  * Adjust timestamps (granule positions), e.g. to start at time 0
>  * Adjust Ogg page durations, to reduce either overhead or streaming delay
>  * Repair some broken files
>  * Remove any CBR packet padding
>  * Add/remove comment/picture padding
>
> Several of these may require re-writing (but not re-encoding) the
> whole file, for example if there is not enough padding space for
> additional comments or attached pictures.  Even if multiple operations
> are performed, the file should be re-written at most once.
>
I suppose the difficulty is many of these are things that apply to
other Xiph formats too, so there's front end handling (tool interface
itself, and handling for things like album art, comment header in
general) that it'd be nice to keep consistent between different tools
and not have to duplicate. Also R128 gain calculation as mentioned by
Timothy Terriberry, for Vorbis I've tended to use the standalone
VorbisGain tool (not familiar with the differences between R128 and
ReplayGain). Liboggz is a nice place for such generalised stuff, but
its tools aren't often included in standard installs (in Linux distros
anyway), even if opus tools or vorbis tools are.

I don't know whether Xiph really wants to get into the media framework
territory that providing common handling for that full list would
require, but maybe a support library (not in libogg, but alongside it)
could provide a common interface for some of the basic metadata stuff
like gain calculation and album art conversion? The more
codec-dependent tasks like handling packet padding or sample accurate
trimming would still need to be handled specifically by individual
X-tools or a framework like liboggz that understands enough about the
different codecs.

Aside: what is the purpose of the original sample rate in the Opus
header? And why would you want to change it? (Other than being
annoying to not be able to.)

-- 
imalone
http://ibmalone.blogspot.co.uk