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
Timothy B. Terriberry
2016-Dec-31 22:25 UTC
[opus] [ogg-dev] comment writing in opus / liboggz
Mark Harris wrote:> * Adjust output gain in headerAn 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