--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote:> > -----Ursprungliche Nachricht----- > > Von: Josh Coalson > > > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > > Hi, > > > > > > have I just overseen a link, or is the format description on > > > http://flac.sourceforge.net/format.html lacking information on > how to > > > actually decode the residual partitions to PCM sample data? > > > > you are correct, it is not explicit enough. the encoded residual > > is a string of Rice codes of the form 000nnn, where 000 is a unary > > portion and nnn is the binary portion of length k, k being the > > rice parameter. but there is a signed->unsigned transform before > > rice coding that needs to be documented. > > Is this something you are working on, and expect to be ready in the > near > future? I took a quick look at the libFLAC sources, but the OO-like > implementation and pointer-shuffling is not very easy to understand.yes, I will probably get to it soon after the release. the encoding side is pretty convoluted but for decoding, src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() should be pretty straightforward once you ignore the FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to ask questions about it here.> The reason I am asking is, that I've started to implement a FLAC > decoder for > the Java Media Frameworkcool, that was on my TODO list but way way down. I'm glad you're doing it :) Josh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you are correct, it is not explicit enough. the encoded residual > is a string of Rice codes of the form 000nnn, where 000 is a unary > portion and nnn is the binary portion of length k, k being the > rice parameter. but there is a signed->unsigned transform before > rice coding that needs to be documented.Is this something you are working on, and expect to be ready in the near future? I took a quick look at the libFLAC sources, but the OO-like implementation and pointer-shuffling is not very easy to understand. The reason I am asking is, that I've started to implement a FLAC decoder for the Java Media Framework, and didn't realize that a part of the format description was missing before I actually needed that part :) Tor
> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > yes, I will probably get to it soon after the release. > the encoding side is pretty convoluted but for decoding, > src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() > should be pretty straightforward once you ignore the > FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to > ask questions about it here.Yes, I did find that part after tracing through the code, and I already have a few questions. - I am right, that the FLAC__bitbuffer_read_rice_signed_block method is doing the same as I would have achieved by filling the array in a loop by calling FLAC__bitbuffer_read_symmetric_rice_signed? - Should I allign the bitstream to the beginning of the next byte between the subframes, or only after reading the last subframe. I'm having some synchronization problems which might be caused by this. - My implementation seems to decode fixed subframes now, but the lpc subframes contains nothing but noise, and the bitstream is out of sync after reading one. The source code I'm using for decoding the lpc subframe is available here: http://user.cs.tu-berlin.de/~bjote/Subframe.java and the relevant part starts on line 218. I would appreciate if someone would take a look at it and see if they find any obvious mistakes (the code should be quite easy to read). Tor