Skip to content

Conversation

@pwnified
Copy link

@pwnified pwnified commented Aug 6, 2023

Not sure if project is still maintained but I added some features that I use, a bugfix or two

pwnified added 2 commits July 12, 2023 02:21
More support for the extensible format including floating point formats.
Simple GUID support for the SubFormat, subFormatString can be removed.
Added function Bw64Writer::writeRaw() allows client to submit samples already processed, dithered, etc. without more conversions. Must match the internal format.
ExtraData::channelMask can be set in constructor as an optional parameter.
TODO: Bw64Writer::write() should allow passthrough of floats directly to float format wavs.
Exception is thrown ("chunk ends after end of file") if the data chunk is the last chunk in the file and it ends on an odd number, and then adding the padding byte pushes it past the end. This fix adds the padding byte only if possible.
@tomjnixon
Copy link
Member

Thanks for the contribution -- yes, we're still alive, there's just not much need for constant changes in a library like this.

re. the padding issue, what software generates files like this? They are invalid; riffmci.pdf says:

If the chunk size is an odd number of bytes, a pad byte with value zero is written after ckData

I'm not keen on accepting invalid files, even if it's just a technicality, as that's what leads to issues like this in the first place. Other software I've tried (sox, ffmpeg, audacity) accepts files with this issue, but writes correctly.

Perhaps this could be dealt with by adding an explicit compatibility mode, or a way to issue warnings.

re. floating point, yeah, that's a good idea. I think it was not added because it's not part of the BW64 spec. There are a few changes required I think:

  • as per your note, this should be supported in the read and write methods
  • i'm not keen on adding more parameters to the Bw64Writer constructor, as it's hard to extend in the future and easy to mess up. I'd probably add a new constructor which accepts a FormatInfoChunk directly, and add setter methods to that.
  • there are a few small changes which should be pulled out into their own commits
  • there's no tests for the new functionality
  • don't use macros for type/subtype definitions, as they break namespacing

I can probably do some of these, but it might be some time before I can work on it.

Thanks again.

- Add CueChunk and LabelChunk classes to support audio markers
- Add parsing and writing functionality for markers in WAV/BW64 files
- Properly handle IEEE float format by adding specialized encoding/decoding
- Replace format macros with constexpr for better type safety
- Add comprehensive test cases for new functionality
- Add ListChunk for standard LIST/adtl chunk for labels
- Fix library to properly handle multiple chunks with same ID
- Add test for serializing/deserializing markers and labels
- CuePoint stores labels directly
- Add marker management methods to Bw64Writer/Reader
- Fix label chunk parsing in LIST chunks
- Simplify API for marker creation and retrieval

TODO: About to set labels into CuePoint on load
TODO: About to use a map for CuePoint id management
TODO: Fix the new tests to return sentinel object for findMarkerById
- Associate label chunks with their cue chucks on file reading
- findMarkerById to return optional pointer instead of sentinel
- Move float tests to float_tests.cpp, other cue tests moved to marker_tests.cpp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants