Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extensible float #49

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Extensible float #49

wants to merge 3 commits into from

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
@pwnified
Support extensible float
962ef64 
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.
@pwnified
Support odd sized data when last chunk
8e57352 
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@pwnified @tomjnixon