You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current API it's not possible to write multiple chunks of the same type. This is needed e.g. for writing a .wav file that contains both a LIST chunk for the INFO chunk and another one for the cue points.
This would allow multiple LIST chunks to be written, and also allow the order of chunks written to be specified (at the moment it depends on Julia's hashing) but it will be a breaking change to the API. We'll have to change wavread as well - we can make it return a Vector{Tuple{Symbol, Array{UInt8,1}} or a Dict{Symbol, Vector{Any}} where the entries in the dictionary are vectors containing all the chunks with a particular ID. I'd tend to go with the first option because it means you could read/write chunks without having to convert between the two types.
@dancasimiro if you approve of this change then I'm happy to implement and test it. If not, let me know your thoughts on other options.
The text was updated successfully, but these errors were encountered:
rjkat
added a commit
to rjkat/WAV.jl
that referenced
this issue
Apr 12, 2018
I am going to wait for other breaking changes before publishing v1.0.0 of the WAV library. I would also like to wait until the FileIO.jl package is updated to support the newest Julia.
With the current API it's not possible to write multiple chunks of the same type. This is needed e.g. for writing a .wav file that contains both a LIST chunk for the INFO chunk and another one for the cue points.
I propose that
wavwrite
be updated as follows:This would allow multiple LIST chunks to be written, and also allow the order of chunks written to be specified (at the moment it depends on Julia's hashing) but it will be a breaking change to the API. We'll have to change
wavread
as well - we can make it return aVector{Tuple{Symbol, Array{UInt8,1}}
or aDict{Symbol, Vector{Any}}
where the entries in the dictionary are vectors containing all the chunks with a particular ID. I'd tend to go with the first option because it means you could read/write chunks without having to convert between the two types.@dancasimiro if you approve of this change then I'm happy to implement and test it. If not, let me know your thoughts on other options.
The text was updated successfully, but these errors were encountered: