The delete file method takes a Path struct: https://doc.rust-lang.org/std/fs/fn.remove_file.html, https://doc.rust-lang.org/std/path/struct.Path.html

Use this type when opening files for read or write; instead of &str

One way to avoid lots of generic parameters is to box the stream. Experiment with boxing it

In #30, protections were added to prevent writing a wave file longer than the RIFF 4GB limit.

One confusing area when consuming this is that the maximum length of a wave file, in samples, should be known before opening the file. This allows the consuming program to reason about the file.

wave_reader and wave_writer are monolithic

Break them up into multiple files:

• Common functionality for opening and metadata
• Stream based logic
• Random-access based logic

In Rust, indexing of arrays and general sizes are typically represented by a usize.

wave_stream currently uses a u32, because the wave header uses u32.

Initially, I believed it was best to keep with the type limitations imposed by the wave format. Instead, I believe it's simpler to keep with Rust semantics for indicating size and location; and have a runtime exception if the wave file is longer than u32::MAX;

(Similar task to #3)

It should be possible to read an 8-bit wav as if it's a float; upconverting to float through the process.

(Likewise, 16-bit should automatically upconvert to 24-bit and float.)

Downconverting, (float -> 8-bit) on read or write will not be supported.

Idiomatic Rust documentation is needed prior to publishing the library

This website explains the channel layout of 5.1 wav files: https://www.jensign.com/bdp95/7dot1voiced/index.html

It then links to a more detailed document from Microsoft about varying channel layout. (IE, how to disambiguate from 3.1 versus quad: https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)?redirectedfrom=MSDN

One important change needed in wave_stream is supporting channelMask

See if builds and tests can run upon commit

Currently, files that are long are truncated. (See GWBasic/soft_matrix#77 )

I've determined this is because RIFF + WAV has limitations imposed by 32-bit lengths specified in the file.

Specifically, https://docs.fileformat.com/audio/wav/ states that bytes 5-8 are the length of the file, in bytes. A 32-bit 6-channel wav that's 2 hours will be 8GB. This overflows RIFF's file length field.

In this bug: Figure out how to construct wav files that are longer than 32-bit RIFF file limits. https://www.loc.gov/preservation/digital/formats/fdd/fdd000001.shtml#notes might explain how to do this.

Note: Wave files > 4GB in length will not be supported. The reason is that there are two competing proposals to alter the wave file format, and support for these file formats in other applications is very limited. A much better approach for files > 4GB is to use an alternate file format, like AIFF.

I currently do not intend on supporting other audio file formats in wave_stream. At some point it may make sense to write a sister library called "aiff_stream," and possibly a library that allows reading and writing both.