mewkiz/flac

Package flac provides access to FLAC (Free Lossless Audio Codec) streams.

flac's Issues

Implement LPC encoding of audio samples

Notes from @wsc1 at #32 (comment)

For the LPC stuff, just wanted to note
this mail

this chapter

and zc lpc

So one possible way to approach flac LPC (the fixed LPC shouldn't require this BTW) would be
to extend zc/lpc to use line spectral pairs, expose the parcor coefficients, and work with some of the quantisation methods in the chapter.

If that is of interest to you, I'm happy to collaborate.

FLAC Encoder, audio sample support

A FLAC stream encoder was implemented as part of #14, which added support for encoding metadata blocks.

From commit 306014a:

Proper support for encoding audio samples is yet to be implemented. For now, simply copy the original encoded audio data from the source FLAC file.

This issue tracks the implementation of support for encoding FLAC stream audio samples.

Implement decoding of FLAC files with wasted bits-per-sample

Add examples for common uses of the API.

• Parse metadata of file.
  • flac.ParseFile
• Open a file for audio streaming without parsing metadata.
  • flac.Open
• Parse the audio samples within audio frames:
  • flac.Stream.ParseNext
• Seek to a specific audio frame without parsing any audio samples:
  • flac.Stream.Next

ref: https://blog.golang.org/examples

proposal: move cmd example tools to external repository (to reduce external dependencies of flac)

This is a proposal to move all tools of the cmd/ subdirectory to a new/external repository (e.g. mewkiz/flac-tools). The main motivation is to reduce the need for external dependencies from the flac core libraries.

Moving cmd/ out from the flac repository would help to remove the following dependencies from the mewkiz/flac Go module:

• github.com/go-audio/audio (only used by cmd/flac2wav and cmd/wav2flac)
• github.com/go-audio/wav (only used by cmd/flac2wav and cmd/wav2flac)

Similarly, #22 is aimed at reducing external dependencies.

An alternative approach to this proposal may be to create additional go.mod files for the cmd/ subdirectory, and thus allowing the mewkiz/flac repository to contain multiple Go modules (each tracking their dedicated dependencies).

CC: @karlek

"frame.Frame.parseHeader: The flac library test cases do not yet include any audio files with block size 192."

frame.Frame.parseHeader: The flac library test cases do not yet include any audio files with block size 192. If possible please consider contributing this audio sample to improve the reliability of the test cases.

Hit this message processing a file. I'd be happy to provide the file, but it's copyrighted material ripped from a CD. Would that work to extract the appropriate test blocks?

project status

This is a meta issue keeping track of the projects status.

It is meant to answer questions such as:

• What is left to be done?
• How stable is the API?
• Which parts of the code needs some love?

flac

flac.go was reviewed at 2013-10-30.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

flac/meta

application.go was reviewed at 2013-11-03.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

cuesheet.go was reviewed at 2013-11-04.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

meta.go was reviewed at 2013-10-30.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

padding.go was reviewed at 2013-11-03.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

picture.go was reviewed at 2013-11-04.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

reader.go was reviewed at 2013-11-04.

• TODO: Consider if readBytes should be incorporated in readerutil, at least if frames also requires this functionality.

seektable.go was reviewed at 2013-11-03.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

streaminfo.go was reviewed at 2013-11-03.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

vorbiscomment.go was reviewed at 2013-11-04.

• The API in it's present form is considered quite stable.
• The documentation and general code quality is fine.

flac/frame

frame.go not yet reviewed.

header.go not yet reviewed.

subframe.go not yet reviewed.

utf8.go not yet reviewed.

Any plans for replaygain scanning support?

Hi. I found this project via search and it looks amazing. I haven't yet had a chance to look at it in detail, so I'm sorry if missed obvious answers to my questions.

Do you think it's worth implementing a feature that repeats metaflac --add-replay-gain behavior?
Does this feature even belong here?

Or should I instead use this project to decode flac to pcm and use something else to determine loudness? Do you happen to know go libraries that would do that?

Thanks

Vendor our dependencies

Since we depend on a few libraries, and a few projects depends on us, it would be high time to start vendoring our dependencies.

The only problem is in deciding which dependancy manager to use. I argue that we first use dep, until vgo leaves the prototype stage. However, bleeding edge is also fun in itself.

What's your take on this @mewmew?

Seek support

From flac.go:

// TODO: Implement a Seek method.

Creating this issue to facilitate an open discussion on how we may implement audio seek support in the future. What do we need to keep in mind?

• Performance?
• How should the API look like?
• Should we require a seek table to be present in the metadata?
• Should we make use of the sync codes to seek when no seek table is present?
• Will we require the underlying stream to implement io.Seeker?

Some notes from the x/audio proposal:

@rakyll wrote at golang/go#13432 (comment)

Seeking is often expensive, we may adopt an io.ReadSeeker-like interface to make Seek a standalone operation to put some more emphasis on its cost.

Slight audio playback issues with some flac files depending on header block size?

Hi. Some of my flac files don't play back perfectly. The issue appears to depend on the block size in the header.
blockSize=12 results in frame.BlockSize=4096 which plays back perfectly.
blockSize=5 results in frame.BlockSize=4608 which comes out slightly scrambled.
Any idea what could be causing this? Thank you.

Replace errutil with pkg/errors

Currently we are using errutils at some places, e.g. https://github.com/karlek/flac/blob/66eeb19133306fb37c2cfa5b3dab532224c734f7/enc.go#L28

At other places, we return the error without added context.

I suggest we change from mewkiz/pkg/errutil to pkg/errors and at the same time make sure to add context to all returned errors. What are your thoughts @karlek?

Flac plays slowly

Hey there. I bought an album in 96/24 format from Bandcamp and all the songs on it play at what sounds like 1/2 speed or maybe less. Following the suggestion from #30 I also tried playing it with github.com/mewspring/blip and I get the same result. However, VLC Media player handles it just fine, so that makes me think there might be a problem with this lib?

The album is Big Thief, U.F.O.F. I don't want to attach the file and get anyone in trouble, but maybe you could point me in the right direction so I might find the problem myself? I started putting a bunch of debug statements all over the place and, whoa, flac is complicated!

Roadmap towards 2.x

Version 1.x

Before move to github.com/ljud. (see #19)

• Remove flac.Encode (done as of #32)
• Rename internal/bits to internal/bitio.
• Copy icza/bitio to internal/bitio to reduce external dependencies.
• Rename enc_test.go to encode_test.go and update to make use of NewEncoder.
• Add encode/decode round-trip test case

Version 2.x

After move to github.com/ljud. (see #19)

• Split flac package into low-level (back-end) and high-level (front-end) packages.
  • The low-level package will handle encoding and decoding on the bit-level, not hiding any FLAC details in the API. The low-level package is intended for users who require full control of FLAC streams, e.g. those who want to write highly optimizing FLAC encoders.
  • The high-level package is intended for end-users and will provide convenient API for accessing audio samples, along with seek support with time.Duration and sample number offsets.
• Make Header and SubHeader of frame.Frame and frame.Subframe pointers instead of values?
• Rename frame.SubHeader.Wasted to WastedBits?
• Check if we could add a Decoder analogous to Encoder, and remove unexported readers from flac.Stream, frame.Frame and frame.Subframe.
• Take the opportunity to reduce repository size? Currently it's at 13 MB.
• Investigate how to update the API to avoid having to duplicating the slice of audio samples for different use cases (ref #34). E.g. playing sound needs samples to be zipped from each channel. Interacting with zc sound.Source requires samples from each channel to be placed after each other; e.g. n samples of the first channel in samples[0:n] and n samples of the second channel in samples[n:2*n].
  • The subframe API should probably be updated to accept a slice to read into, rather than allocating it's own slice. Exactly how to do this while catering towards both zipped and unzipped data is not yet determined.

Re-Implement the flac.Encode(f, stream) function

Hi, It's great that you're attempting to implement a new encoder API, but after some testing with it I've not got a path forward with existing files, which are using a non-implemented prediction codec:

ERROR: github.com/mewkiz/flac.encodeSubframe (encode_subframe.go:38): error: support for prediction method 3 not yet implemented

Previously, I could use flac.Encode(...) to achieve simple metadata editing, which works on those files but that was removed in favour of the new Encoder API.

Looking for a suggestion as to how best to proceed - should I attempt to re-implement the flac.Encode function within my own code, or is there something I'm missing when trying to change just the metadata, and not the samples.

investigate why some encoding test cases are failing

The #66 PR adds support for LPC encoding of audio samples (and thus resolving #35).

While many test cases pass for round-trip decoding/encoding of FLAC files, producing bit-by-bit identical input and output files, there are still a lot of test cases that produce different output files (during encoding) for a given input file.

This issue tracks the investigation of why these test cases are failing, and also calls for help from the community to join us in the investigation.

Cheerful regards,
Henry & Robin

flac.Parse funcs are prone to data races

Hello! Thanks for the wonderful library!

I'm trying to Parse multiple .flac files concurrently where each file is being parsed by its own goroutine (not multiple goroutines parsing 1 file). Getting some flakey results because readBytes func uses a global buffer and is prone to data races.

Is there any harm not using this global buffer? Could make a slice of size n in the func itself - would allocate it on the stack up until a certain size I think.

This is the commit that introduced this: e03baec (I know it's pretty old :/ )

IETF test cases - 1 of 64 FAIL (63 of 64 PASS) in frame.TestFrameHash (decoding audio samples)

This issue is a follow-up on #54 (which handles FLAC stream decoding). In particular, this issue handles issues of FLAC audio sample decoding (e.g. mismatch between expected audio samples and decoded audio samples).

The IETF flac-test-files repository contains 64 FLAC files, published by @ktmf01, which help exercise corner cases of the FLAC decoder.

When adding these test cases to the test suite, 7 of 64 FLAC files resulted in audio sample decoding failures, namely:

    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/16_-_partition_order_8_containing_escaped_partitions.flac (0.05s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/22_-_12_bit_per_sample.flac (3.24s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/32_-_high_resolution_audio,_partition_order_8_containing_escaped_partitions.flac (0.14s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/37_-_20_bit_per_sample.flac (11.43s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/62_-_predictor_overflow_check,_20-bit.flac (1.63s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/63_-_predictor_overflow_check,_24-bit.flac (0.01s)
    --- FAIL: TestFrameHash/../testdata/flac-test-files/subset/64_-_rice_partitions_with_escape_code_zero.flac (0.01s)

This issue tracks the resolution of the identified decoding issues.

• 16_-_partition_order_8_containing_escaped_partitions.flac
• 22_-_12_bit_per_sample.flac
• 32_-_high_resolution_audio,_partition_order_8_containing_escaped_partitions.flac
• 37_-_20_bit_per_sample.flac
• 62_-_predictor_overflow_check,_20-bit.flac
• 63_-_predictor_overflow_check,_24-bit.flac
• 64_-_rice_partitions_with_escape_code_zero.flac

To reproduce, run:

go test -v github.com/mewkiz/flac/frame

Remember to initiate the submodule for IETF test cases in the testdata/flac-test-files directory:

git submodule update --init --recursive

Convert problem in the flac2wav

I don know how to deal with this problem flac.parseStreamInfo: invalid FLAC signature; expected "fLaC" got "\xcf\xfa\xed\xfe. When I try to convert a Flac file to wav, the terminal shows this.

It's strange that at first I succeeded to convert one file, but after that, I couldn't succeed, even using the examples provided by the author
Looking for the cause and solution.
Hopefully

`flac.parseStreamInfo` reports wrong type when first block is not `STREAMINFO`

I happen to have some files where the first metadata block is not a STREAMINFO, but a PICTURE (this is totally bogus, of course).

The problem is reported as follows:

	si, ok := block.Body.(*meta.StreamInfo)
	if !ok {
		return block, fmt.Errorf("flac.parseStreamInfo: incorrect type of first metadata block; expected *meta.StreamInfo, got %T", si)
	}

However, thanks to the type assertion, si will always be a *meta.StreamInfo (albeit nil when !ok).

The error should probably report block.Header.Type instead.

FLAC Encoder, metadata support

I want to update some metadata blocks (Vorbis comments) and re-encode the Stream.
Is it planned? If not, any hints on how to do it (within the current API design)?

I love how close this library is to the FLAC specifications, I enjoyed using it, thank you.

24/96 flac content

Are 24 bps 96khz flac files supported in general? Has anyone played back such content via mewkiz/flac? With the help of mewkiz/flac and gordonklaus/portaudio I am able to play back standard 16/44.1 flac files (some perfectly / some almost perfectly, see #29 ). However, I'm not yet able to play back 24/96 files in the same way. The problem is most likely in my code. But it could also be an issue in either mewkiz/flac or gordonklaus/portaudio. This is why I would like to ask if anybody has managed to play back 24/96 flac content from their Go app. (I can play back 24/96 flac files via VLC to my USB DAC in bitperfect fashion. Just not via my Go app, yet.) Thank you.

Coping with damaged flac files

Hi. With some flac files (rather rare, but still) I get "crc mismatch" messages, either on startup or at some later point during playback. In some cases I see an additional message such as this: "frame.Subframe.decodeRicePart: The flac library test cases do not yet include any audio files with Rice parameter escape codes. If possible please consider contributing this audio sample to improve the reliability of the test cases." Is it fair to assume that an internally damaged flac file could cause such a message to show up? All crc mismatch messages lead to a program abort, which is not ideal.

In some cases I didn't get a crc mismatch message, but a direct array overrun panic. I added three "if" statements to make the code skip over these situations. I have not seen a single array overrun since. See my code changes ("tmtmtm") below. Do you agree that making the decoder more robust against damaged flac files is a reasonable goal?

frame.go:

func (frame *Frame) correlate() {
	switch frame.Channels {
	case ChannelsLeftSide:
		// 2 channels: left, side; using inter-channel decorrelation.
		left := frame.Subframes[0].Samples
		side := frame.Subframes[1].Samples
		for i := range side {
			// right = left - side
			if i<len(left) {	                   // tmtmtm
				side[i] = left[i] - side[i]
			}
		}

subframe.go:

func (subframe *Subframe) decodeLPC(coeffs []int32, shift int32) error {
	if len(coeffs) != subframe.Order {
		return fmt.Errorf("frame.Subframe.decodeLPC: prediction order (%d) differs from number of coefficients (%d)", subframe.Order, len(coeffs))
	}
	if shift < 0 {
		return fmt.Errorf("frame.Subframe.decodeLPC: invalid negative shift")
	}
	for i := subframe.Order; i < subframe.NSamples; i++ {
		var sample int64
		for j, c := range coeffs {
			if i-j-1 < len(subframe.Samples) {	     // tmtmtm
				sample += int64(c) * int64(subframe.Samples[i-j-1])
			}
		}
		if i<len(subframe.Samples) {	                    // tmtmtm
			subframe.Samples[i] += int32(sample >> uint(shift))
		}
	}
	return nil
}

[Feature Request] Add the ability to skip ID3 tags/ID3 data

The library expects a flac signature but doesn't skip over ID3 data to try to find it.

FLAC decoder testbench

I just found your FLAC decoding library, and tested it through flac2wav with this FLAC decoder testbench. I got quite a lot of messages like these

The flac library test cases do not yet include any audio files with xxx. If possible please consider contributing this audio sample to improve the reliability of the test cases.

For this I recommend the FLAC decoder testbench I just linked.

Besides the messages, flac2wav fails to decode the following files:

• 16 - partition order 8 containing escaped partitions
• 22 - 12 bit per sample
• 32 - high resolution audio, partition order 8 containing escaped partitions
• 37 - 20 bit per sample

Also, decoding of 23 - 8 bit per sample seems to be non-lossless.

I hope this information helps you to even further improve this library.

bug: HasFixedBlockSize

HasFixedBlockSize field has inverted state.

from https://xiph.org/flac/format.html#frame_header

0 : fixed-blocksize stream; frame header encodes the frame number
1 : variable-blocksize stream; frame header encodes the sample number

but in code:

    // 1 bit: HasFixedBlockSize.
    x, err = br.Read(1)
    if err != nil {
        return unexpected(err)
    }
    if x != 0 {
        frame.HasFixedBlockSize = true
    }

Error when downloading package

C:\py\e>go get github.com/mewkiz/flac

github.com/mewkiz/flac

..\go\src\github.com\mewkiz\flac\encode.go:55:28: cannot use bw (type *bitio.Wri
ter) as type bitio.Writer in argument to encodeStreamInfo
..\go\src\github.com\mewkiz\flac\encode.go:59:24: cannot use bw (type *bitio.Wri
ter) as type bitio.Writer in argument to encodeBlock
..\go\src\github.com\mewkiz\flac\encode.go:98:29: cannot use bw (type *bitio.Wri
ter) as type bitio.Writer in argument to encodeStreamInfo
..\go\src\github.com\mewkiz\flac\encode_frame.go:69:27: cannot use bw (type *bit
io.Writer) as type bitio.Writer in argument to encodeSubframe
..\go\src\github.com\mewkiz\flac\encode_frame.go:120:57: cannot use bw (type *bi
tio.Writer) as type bitio.Writer in argument to encodeFrameHeaderBlockSize
..\go\src\github.com\mewkiz\flac\encode_frame.go:126:81: cannot use bw (type *bi
tio.Writer) as type bitio.Writer in argument to encodeFrameHeaderSampleRate
..\go\src\github.com\mewkiz\flac\encode_frame.go:132:37: cannot use bw (type *bi
tio.Writer) as type bitio.Writer in argument to encodeFrameHeaderChannels
..\go\src\github.com\mewkiz\flac\encode_frame.go:137:42: cannot use bw (type *bi
tio.Writer) as type bitio.Writer in argument to encodeFrameHeaderBitsPerSample
..\go\src\github.com\mewkiz\flac\encode_meta.go:154:25: cannot use bw (type biti
o.Writer) as type io.Writer in argument to binary.Write:
bitio.Writer does not implement io.Writer (Write method has pointer rece
iver)
..\go\src\github.com\mewkiz\flac\encode_meta.go:183:24: cannot use bw (type biti
o.Writer) as type io.Writer in argument to binary.Write:
bitio.Writer does not implement io.Writer (Write method has pointer rece
iver)
..\go\src\github.com\mewkiz\flac\encode_meta.go:183:24: too many errors

C:\py\e>

Last call on FLAC spec

Sorry for bothering you this way, I really hope you don't mind.

To implement FLAC decoding in your flac implementation, you might have used the FLAC format specification on the FLAC website. If so, you probably needed to dive into some actual code (libFLAC or ffmpeg) to understand the finer points. An IETF working group has tried to improve this document, trying to include those finer points, and is on the verge of turning it in for final checks and publication as an RFC. A so-called working group last call has been issued, which lasts 2 weeks.

As you've had first-hand experience implementing FLAC from scratch, you probably know best what implementation details needed extra attention. It would be very valuable to have your feedback on the FLAC format for this document.

I hope you can provide some insights.

The latest draft can be found here https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/

IETF test cases - 3 of 64 FAIL (61 of 64 PASS) in flac.TestDecode

The IETF flac-test-files repository contains 64 FLAC files, published by @ktmf01, which help exercise corner cases of the FLAC decoder.

When adding these test cases to the test suite, 3 of 64 FLAC files resulted in decoding failures, namely:

    --- FAIL: TestDecode/parse/testdata/flac-test-files/subset/16_-_partition_order_8_containing_escaped_partitions.flac (0.00s)
    --- FAIL: TestDecode/parse/testdata/flac-test-files/subset/32_-_high_resolution_audio,_partition_order_8_containing_escaped_partitions.flac (0.00s)
    --- FAIL: TestDecode/parse/testdata/flac-test-files/subset/64_-_rice_partitions_with_escape_code_zero.flac (0.00s)

This issue tracks the resolution of the identified decoding issues.

• 16_-_partition_order_8_containing_escaped_partitions.flac
• 32_-_high_resolution_audio,_partition_order_8_containing_escaped_partitions.flac
• 64_-_rice_partitions_with_escape_code_zero.flac

Further tests will be run to also exercise e.g. metadata decoding and decoding of all audio samples.

Update seek API to use absolute rather than relative sample number

After playing around with the seek API implemented in #44, @karlek and I noticed one minor issue with the API. The flac.Stream does not keep track of the current sample number, so relative seek becomes inaccurate.

The flac.Stream can only keep track of where the reader is in the frame, and as such position the reader such that the next call to stream.ParseNext returns a frame which includes the sample number the user wants to seek to.

A high-level audio playback API or application can keep track of the current sample number (i.e. the current index into the frame.SubFrames[i].Samples slice), but such information is unavailable to the FLAC frame decoder, as it only works on the resolution of frames (and not sample numbers).

Therefore, the best the low-level mewkiz/flac API can do is to position the reader of the flac.Stream such that the next call to stream.ParseNext returns the frame which includes the frame number the user wants to seek to.

And since the flac.Stream does not keep track of the current sample number (at best, it can track the first sample number of the current frame, but not with higher precision on sample number than that) the best approach would be to use absolute rather than relative sample number in the API of Seek.

@karlek has a proof of concept implementation on his laptop. He'll submit a PR in the following days.

Another aspect is that the seek API should seek to the frame containing the sample number the user wants to seek to. The current implementation seeks to the closest seek point.

All in all, these are minor changes to the seek API, but essential to have a solid low-level API on which high-level audio playback APIs and applications can build upon. It would be the task of such high-level APIs to keep track of the current sample number.

The low-level mewkiz/flac API only handles decoding of FLAC streams at the resolution of frames, not the resolution of samples.

So, the suggested see API would look as follows:

// Seek seeks to the frame containing the given absolute sample number. The return value
// specifies the first sample number of the frame containing sampleNum.
func (stream *Stream) Seek(sampleNum uint64) (frameSampleNum uint64, err error)

Reason for using sized integer types in `StreamInfo` and `frame.Header`

Hi there! I've been playing around with a small audio streaming project in go using this library. Thanks for the great work :)

I was wondering why you chose to use unsigned and sized integer types for all of the values in StreamInfo? Did you find that this provided a measurable performance benefit?
My expectation would be that using types other than int would provide little to no performance benefits on a 32bit or 64bit architecture. The go documentation recommends generally using int unless there is a specific reason not to.

It makes working with the library quite tedious because of the high number of conversions between integer types required when performing logic or calculations with the StreamInfo and frame.Header fields. One of the first things I have done is write my own equivalent type with ints. I have a strong aversion to boilerplate unless it serves a purpose so it'd be good to understand what drove this decision.

I'd be happy to submit a pull request if you think that this would be a good change. However it would be a breaking change so perhaps best bundled with other breaking changes for a future major release.

API overhaul

The flac library has evolved organically and is now at a state where it is capable of decoding the metadata and audio data of arbitrary FLAC files. The API was designed in an ad-hoc fashion. We are now preparing for a complete API overhaul, which will be based on our experience with the current API. The main focus is to get a consistent API that feels lightweight and well designed.

This issue will track the development of the new API and encourages discussion about its design.

ci: replace Travis CI with Github actions for continuous build and test runs

Anyone who feels like contributing, we'd like to update our CI pipeline (from Travis CI) to use GitHub actions to build and test mewkiz/flac.

The test action should include git submodule update --init --recursive to download the IETF test cases (i.e. the mewkiz/flac/testdata/flac-test-files/ Git submodule) prior to running go test github.com/mewkiz/flac/... (see #60 (comment) for an example).

If it's possible to cache the download of IETF test cases in such a way that they don't have to be re-downloaded each time, that would also be wonderful since the test cases amount to some 250 MB.

Cheers,
Robin

Proposed move of flac to github.com/ljud/flac

To welcome contributions and collaboration with anyone from the open source community, we've been considering to move the flac repository to the newly created GitHub organization ljud (which means sound in Swedish). Anyone interested in working on audio and sound libraries, feel free to reach out to either of us, and we'll send you an invite to the new organization.

With this move, we can also take a closer look at the API of the flac package and associated frame and meta packages. Is the API well defined, consistent and as clean? Are there any parts that could be updated when we do the move.

The intention is to make a transition as smooth as possible, and we also intent to send PRs to the main game engines, music players, and other repositories using mewkiz/flac as a backend for FLAC decoding.

For now, the list of users includes (feel free to add to this list if you are using github.com/mewkiz/flac currently):

• Audio playback library: https://github.com/faiface/beep
• Azul3D game engine: https://github.com/azul3d/engine
• Music player: https://github.com/mjibson/moggio
• Example code: https://github.com/wjblack/goflacook
• Album tag checker: https://github.com/varyoo/albumpact
• FLAC tools: https://github.com/lpar/flactools
• Media content management system: https://github.com/brendoncarroll/friendflix
• Audio server: https://github.com/zenathark/astream
• Music player: https://github.com/cswank/mcli
• Music player: https://github.com/And678/goPlayer

Some users of the flac package may be located using GoDoc.org https://godoc.org/github.com/mewkiz/flac?importers

EDIT: Oh, and to keep the code running and make the transition as smooth as possible we can try using vanity imports.

Cheers,
Henry and Robin

Audio Compression

Hi,
I'm interested to know if this package compresses audio when encoding it to flac. I have tried out the wav2flac program in the cmd folder however when given a 5 second stereo wav file sampled at 48kHz, the flac file produced is larger by 240kb.

Since wav is uncompressed and flac is supposed to be encoded using lossless compression, I was expecting a smaller file size. Am I missing something?
Thanks,
-Trek

Sample with Rice parameter escape codes

invalid-residual.flac.zip

This triggered:

frame.Subframe.decodeRicePart: The flac library test cases do not yet include any audio files with Rice parameter escape codes. If possible please consider contributing this audio sample to improve the reliability of the test cases.

The sample is a corruption of https://freesound.org/people/krestivo/sounds/27951/

Fix issues reported by golangci-lint

I started a branch to make use of golangci-lint. Currently it reports the following issues:

https://travis-ci.org/mewkiz/flac/builds/384037888

u@x220 ~/D/g/s/g/m/flac> golangci-lint run --enable-all
frame/frame.go:212:1: cyclomatic complexity 52 of func `(*Frame).parseHeader` is high (> 30) (gocyclo)
func (frame *Frame) parseHeader() error {
^
meta/cuesheet.go:30:1: cyclomatic complexity 37 of func `(*Block).parseCueSheet` is high (> 30) (gocyclo)
func (block *Block) parseCueSheet() error {
^
meta/streaminfo.go:4: G501: Blacklisted import crypto/md5: weak cryptographic primitive (gas)
	"crypto/md5"
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 {
	                                ^
meta/cuesheet.go:204:20: struct of size 64 bytes could be of size 56 bytes (maligned)
type CueSheetTrack struct {
                   ^
meta/meta.go:122:13: struct of size 24 bytes could be of size 16 bytes (maligned)
type Header struct {
            ^
cmd/go-metaflac/metaflac.go:82:2: unnecessary nil check around range (megacheck)
	if blockNums != 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[:])
				            ^
frame/utf8.go:11:2: `t1` is unused (varcheck)
	t1 = 0x00 // 0000 0000
	^

High bitrate, small devices

Hi. Playing hires audio on a RPi can easily drive 50-70% cpu load. You live by the "Output underflowed" message. It only takes another high priority task (sshd) to move a little finger and... bang. But CPU load could be brought down easily. All it would take is for the decoder to interleave the audio channels: LLLLRRRRLLLLRRRRLLLLRRRR... Audio subsystems prefer it this way. Other decoders do this too. Can we have frame.Samples[i] without subframes? Would it be possible to pick the outgoing format when opening a file? Thank you for considering

frame: Implement a CRC-reader.

Implement a CRC-reader which reads data and calculates the CRC checksum at the same time.

Importing Repo

Cannot install package due to directory name.

Example:

go get -u github.com/mdlayher/waveform
package github.com/mdlayher/waveform
        imports github.com/azul3d/audio-flac
        imports gopkg.in/mewkiz/flac.v1/frame
        imports github.com/mewkiz/flac/internal/bits: use of internal package not allowed
package github.com/mdlayher/waveform
        imports github.com/azul3d/audio-flac
        imports gopkg.in/mewkiz/flac.v1/frame
        imports github.com/mewkiz/flac/internal/hashutil: use of internal package not allowed
package github.com/mdlayher/waveform
        imports github.com/azul3d/audio-flac
        imports gopkg.in/mewkiz/flac.v1/frame
        imports github.com/mewkiz/flac/internal/hashutil/crc16: use of internal package not allowed
package github.com/mdlayher/waveform
        imports github.com/azul3d/audio-flac
        imports gopkg.in/mewkiz/flac.v1/frame
        imports github.com/mewkiz/flac/internal/hashutil/crc8: use of internal package not allowed

Which string literal should we use for flac signature?

Is there any preference in choosing double quotes ( "fLaC" ) instead of back qoutes ( fLaC)?