search for: nartowicz

At some stage (possibly commit r17268) oggpack_writecopy started to fail with some strings longer than 256 bytes and all strings longer than 512 bytes. Also it thrashes the stack with very long strings. Lithopsian

...n be done? Tricky. How about some examples of files that show problems? Here is a basic OggFlac track, as produced by the standard flac encoder. It has a vorbis comment packet, a seektable packet, and a padding packet and works fine. Note that each packet is on a separate Ogg page. http://www.nartowicz.webspace.virginmedia.com/oggflac/01.oga Here is the same track with just a vorbis comment packet. The Ogg packet is padded with about 1024 nulls. It also seems to work in all the tools I've tried. I can play this and adjust the padding to edit the metadata in place. http://www.nartowicz.web...

Hi all, I'm having a little trouble with a Vorbis decoder hanging (actually hard looping the CPU) when I call ov_pcm_seek(&vorbis_file, 0) on a multiplexed theora/vorbis file. It appears to be the vorbisfile library that has the problem. The call to ov_pcm_seek never returns. Seeking in non-multiplexed, including chained, files is OK. Seeking to other values, including sample 1, works

>b) According to http://wiki.xiph.org/OggOpus#Comment_Header >there should be no REPLAYGAIN_*** tags in Opus files; Opus uses >R128_TRACK_GAIN tag. If some audio player reads Opus tags then it should >be aware of the difference between ReplayGain and R128. But this doesn't >require REPLAYGAIN_REFERENCE_LOUDNESS tag. > > The Opus replaygain spec is fundamentally broken, so

On Wed, 18 Jun 2014 16:39:12 -0700 "Timothy B. Terriberry" <tterribe at xiph.org> wrote: >Ian Nartowicz wrote: >> The Opus replaygain spec is fundamentally broken, so let's ignore that for >> now. It is discussed ad nauseam elsewhere, but isn't going to change any >> time soon. > >I haven't seen anyone make any concrete proposals for how it should >change. May...

Ian's explanation below was helpful: On Thu, Aug 14, 2014 at 7:53 AM, Ian Nartowicz <ian at nartowicz.co.uk> wrote: > The sample rate should take care of itself. I suspect your difficulty is how > the 24 bit samples are represented in the WAV data and how to pack them into > the Flac buffer? > > WAV samples are stored in either 8, 16, or 32 bit words, using t...

I've developed a function for updating Flac metadata blocks inside Ogg files. Obviously it is desirable to use padding so that most edits don't require rewriting massive files. Although the flac encoder creates a padding metadata block by default in Ogg Flac files, this appears to be useless. When packets on an Ogg page change size, the page size may change by as different amount, hence

Ian Nartowicz wrote: > The Opus replaygain spec is fundamentally broken, so let's ignore that for > now. It is discussed ad nauseam elsewhere, but isn't going to change any time > soon. I haven't seen anyone make any concrete proposals for how it should change. Maybe I missed something....

Ian Nartowicz wrote: > It is certainly the biggest issue. Sure it should be simple to address, but > nobody seems willing to do so. The only response I've had so far is that the > output gain should *always* be applied, yet it *might* be an album gain. It > can't be both and there is no wa...

Hi, In the last days I've been taking as reference the example found in examples/c/encode/file/main.c. With it I've been able to encode a 2ch, 16 bps, 44100 sample rate input WAV file to a FLAC file. Now I've been trying to modify this example to encode a 2ch, 24 bps, 96000 sample rate WAV file. I have to say I'm a bit lost on how I should read the input file in this case, and

Ian Nartowicz wrote: > I use it :) To optionally allow adjustment of tracks containing different > types of gain tag to a similar overall loudness. Admittedly this isn't > common. Files using the original replaygain algorithm with a reference > loudness of 83dB are now very rare, but R128 tag...

On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote: >Erik de Castro Lopo wrote: > >> It sees that the most serious bug in the flac bug tracker: >> >> https://sourceforge.net/p/flac/bugs/413/ >> >> has been fixed in git. This fix alone is worth a new release so its >> time to work towards one. >> >> Things I need

>The use of R128 also raises the question about "REPLAYGAIN_REFERENCE_LOUDNESS" >tag. Currently flac/metaflac writes "REPLAYGAIN_REFERENCE_LOUDNESS=89.0 dB" >but doesn't use it when decoding (it seems that nothing uses this tag). >R128 defines reference level differently, so this tag makes little sense for >it. IMHO it's better not to write this tag when