Roadmap towards 2.x

[mewmew]

Version 1.x

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

• Remove flac.Encode (done as of flac: add Encoder API to encode audio samples and metadata blocks #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 High bitrate, small devices  #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.

[wsc1]

Just curious, why seek with time.Duration? the frame number is more precise, and necessary in the context of DAWs splicing, etc, which might use a flac backend.

[mewmew]

Just curious, why seek with time.Duration? the frame number is more precise, and necessary in the context of DAWs splicing, etc, which might use a flac backend.

I've updated the seek bullet item now to include sample numbers as well. The time.Duration version of seek is mainly intended for end-users wishing to implement music players and the like, where sample number perfection is less important than the intuition of API to say, seek to the time point 01:00 in the song.

As of late, @mehrvarz has been playing around with getting a FLAC music player to work on raspberry pi. Thus helping to uncover where the API falls short for such use cases.