* flac: encode frame header
* flac: calculate CRC-8 when encoding frame headers
* flac: fix encoding of frame header
* flac: add preliminary subframe encoder
* flac: fix UTF-8 encoding of frame number
* frame: add sanity check for sample count in decodeLPC
Updates #31.
* flac: update flac encoding API, depricate flac.Encode
Encode has been removed in favour of using NewEncoder.
The Encode function was temporarily added to support
re-encoding FLAC streams to update the metadata, but
it had no support for encoding audio samples.
The added flac.Encoder has support for encoding both
metadata and audio samples. It also does not require
that you first decode a FLAC file to later re-encode
it by calling Encode (as was the previous behaviour).
* flac: add MD5 running hash of unencoded audio samples to StreamInfo
* flac: remove unused encodePadding
Reported by golangci
* flac: fix golangci lint issues
frame/utf8.go:57:6: `decodeUTF8Int` is unused (deadcode)
func decodeUTF8Int(r io.Reader) (n uint64, err error) {
^
internal/utf8/encode.go:32:16: unnecessary conversion (unconvert)
bits = uint64(t2 | (x>>6)&mask2)
^
internal/utf8/encode.go:37:16: unnecessary conversion (unconvert)
bits = uint64(t3 | (x>>(6*2))&mask3)
^
internal/utf8/encode.go:42:16: unnecessary conversion (unconvert)
bits = uint64(t4 | (x>>(6*3))&mask4)
^
* flac: fix golangci lint issues
encode_frame.go:89:1: cyclomatic complexity 52 of func `(*Encoder).encodeFrameHeader` is high (> 30) (gocyclo)
func (enc *Encoder) encodeFrameHeader(w io.Writer, hdr frame.Header) error {
^
internal/utf8/encode.go:66:17: unnecessary conversion (unconvert)
bits := uint64(tx | (x>>uint(6*i))&maskx)
^
encode_subframe.go:105:46: unnecessary conversion (unconvert)
if err := bw.WriteBits(uint64(sample), byte(hdr.BitsPerSample)); err != nil {
^
* flac: clarify that frame.Header.Num is calculated by the encoder
* flac: minor re-phrasing
This has been tested with FLAC files containing
a lot of samples and a small block size, thus
having frame.Num make use of up to four
continuation bytes.
enc.go:178:35: unnecessary conversion (unconvert)
if err := enc.bw.WriteBits(uint64(si.NSamples), 36); err != nil {
^
enc.go:543:34: unnecessary conversion (unconvert)
if _, err := enc.bw.Write([]byte(pic.Data)); err != nil {
^
frame/frame.go:161:17: Error return value of `md5sum.Write` is not checked (errcheck)
md5sum.Write(buf[:1])
^
frame/frame.go:165:17: Error return value of `md5sum.Write` is not checked (errcheck)
md5sum.Write(buf[:2])
^
frame/frame.go:170:17: Error return value of `md5sum.Write` is not checked (errcheck)
md5sum.Write(buf[:])
^
Updates #25.
Use frame.Open instead of frame.ParseFile to seek past metadata in the frame
decoding test case. Metadata test cases are handled separately in the meta
package.
Test a corpus of 585 public domain FLAC files with a duration of less than 1 minute from freesound.org.
Out of these files, the following increased code coverage and where thus added to the test suit.
* 19875 (sample rate 48 kHz)
* 44127 (8 bits-per-sample, sample rate 22254)
* 80574 (sample rate 22050)
* 191885 (block size 1, verbatim)
* 212768 (sample rate 88200)
* 220014 (utf-8 continuation byte)
* 243749 (sample rate 8000)
* 257344 (sample rate 32000)
* 256529 (sample rate 192000)
Because Josh didn't have complete understanding of LPC analysis back in < 2006 many developers over the years have disputed over negative shifts. Should the switch direction? Should the roll around? Nobody knows. Not even Josh.
The answer finally came to us when Josh stepped forward and told us the truth.
What else has Josh put us through? Is fLaC a lie?
http://lists.xiph.org/pipermail/flac-dev/2006-December/002030.html
- Karlek
I believe panics should be reserved to internal invariant violations or
irrecoverable errors, not invalid user inputs. Also, they are triggered
by go-fuzz, removing them helps testing the package.
- the linear predictive coding has an overflow error -- with FIR-encoded frames, this often causes the output signal to be noise rather than what it should be. Type-converting to int64 to do the summation, then back to int32 after shifting fixed this for the files that I tested against.
- the check if the Rice parameter was the escape code did not handle the 5-bit escape code -- it checked for 0x1f and a 4-bit-long code instead of a 5-bit-long one
I don't have any FLAC files that test the latter issue; I have a number of FLAC files that caused the former, all of which have
DataHoarder
