Going in details through the FLAC format specification, I realize that there are 2 rice coding methods now supported for residual encoding. I thought I remembered in the 1.1.3 times that there was only 1 method (with 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change log, I didn't find any reference to such an addition to the format. Now, the decoder implementation I'm working on only implements the 4-bit-parameter-method; I've been using it extensively, including on files encoded with the reference encoder v1.2.1, and never stumbled on that second method. Does the reference encoder implement that yet ? Thanks, Pyt. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20080103/a3475311/attachment.html
yeah the chnage is not entered in the change log.. it helps in achieving better compression for 24 bit files.. an i think it came in as a mistake cvs merge in 1.2.1 encoder .. neways i think Josh's( jcoalson ) reply on this thread is helpfull http://www.hydrogenaudio.org/forums/lofiversion/index.php/t57624.html my guess is u r not using 24 bit files thts why older decoder is able to decode it.. an then again not all 24 bit files will make use of that enhacement :) On 1/3/08, Pyt <py.thoulon@gmail.com> wrote:> > Going in details through the FLAC format specification, I realize that > there are 2 rice coding methods now supported for residual encoding. I > thought I remembered in the 1.1.3 times that there was only 1 method (with > 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change log, > I didn't find any reference to such an addition to the format. > > Now, the decoder implementation I'm working on only implements the > 4-bit-parameter-method; I've been using it extensively, including on files > encoded with the reference encoder v1.2.1, and never stumbled on that > second method. Does the reference encoder implement that yet ? > > Thanks, > Pyt. > > _______________________________________________ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20080103/59af8b53/attachment.htm
Yup, I'm indeed only dealing with 16 bit files for the time being. Thanks for the hint. Pyt. On Jan 3, 2008 8:43 AM, <ameyap@gmail.com> wrote:> yeah the chnage is not entered in the change log.. it helps in achieving > better compression for 24 bit files.. an i think it came in as a mistake cvs > merge in 1.2.1 encoder .. > neways i think Josh's( jcoalson ) reply on this thread is helpfull http://www.hydrogenaudio.org/forums/lofiversion/index.php/t57624.html > > my guess is u r not using 24 bit files thts why older decoder is able to > decode it.. an then again not all 24 bit files will make use of that > enhacement :) > > On 1/3/08, Pyt <py.thoulon@gmail.com> wrote: > > > Going in details through the FLAC format specification, I realize that > > there are 2 rice coding methods now supported for residual encoding. I > > thought I remembered in the 1.1.3 times that there was only 1 method > > (with 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change > > log, I didn't find any reference to such an addition to the format. > > > > Now, the decoder implementation I'm working on only implements the > > 4-bit-parameter-method; I've been using it extensively, including on files > > encoded with the reference encoder v1.2.1, and never stumbled on that > > second method. Does the reference encoder implement that yet ? > > > > Thanks, > > Pyt. > > > > _______________________________________________ > > Flac-dev mailing list > > Flac-dev@xiph.org > > http://lists.xiph.org/mailman/listinfo/flac-dev > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20080103/1936fe77/attachment.htm