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.

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

writes/reads int32 when should be float32 #10

Closed
bjarthur opened this issue Feb 19, 2014 · 5 comments
Closed

writes/reads int32 when should be float32 #10

bjarthur opened this issue Feb 19, 2014 · 5 comments

Comments

@bjarthur
Copy link
Contributor

the documentation says that writing single precision floating points with nbits set to 32 should yield an output format of single, and that reading that file back in with format set to native should yield singles. yet when doing so i get int32s:

julia> tmp=rand(Float32,(10,2))
10x2 Array{Float32,2}:
0.109329 0.989609
0.257236 0.85028
0.217792 0.777978
0.017634 0.908059
0.156419 0.856639
0.895819 0.0867863
0.654237 0.463306
0.65422 0.0102742
0.52785 0.570494
0.805634 0.950643

julia> wavwrite(tmp,"foo.wav"; nbits=32)
IOStream()

julia> y, fs, nbits, extra = wavread("foo.wav"; format="native")
(
10x2 Array{Int32,2}:
234782656 2125169024
552409408 1825961856
467705728 1670695168
37868812 1950040832
335908000 1839618816
1923755904 186372160
1404963968 994941248
1404926336 22063738
1133548928 1225126400
1730085504 2041490816,

0x00001f40,0x0020,None)

julia> y, fs, nbits, extra = wavread("foo.wav")
(
10x2 Array{Float64,2}:
0.109329 0.989609
0.257236 0.85028
0.217792 0.777978
0.017634 0.908059
0.156419 0.856639
0.895819 0.0867863
0.654237 0.463306
0.65422 0.0102742
0.52785 0.570494
0.805634 0.950643 ,

0x00001f40,0x0020,None)

@bjarthur
Copy link
Contributor Author

i should add that were this a write problem, then it might be related to issue #7. also, here's my version info:

julia> versioninfo()
Julia Version 0.3.0-prerelease+1578
Commit 052869f* (2014-02-14 13:00 UTC)
Platform Info:
System: Linux (x86_64-redhat-linux)
CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
LAPACK: libopenblas
LIBM: libopenlibm

julia> Pkg.status()
6 required packages:

  • ClusterManagers 0.0.1
  • Debug 0.0.0
  • Devectorize 0.2.1
  • Distributions 0.3.4
  • MAT 0.2.2
  • WAV 0.2.2

7 additional packages:

  • ArrayViews 0.4.0
  • BinDeps 0.2.12
  • HDF5 0.2.17
  • NumericExtensions 0.4.3
  • StatsBase 0.3.6
  • URIParser 0.0.1
  • Zlib 0.1.3

@dancasimiro
Copy link
Owner

The wavwrite function uses the PCM format by default. You need to specify IEEE float (compression=WAVE_FORMAT_IEEE_FLOAT) when you write the file:

wavwrite(tmp,"foo.wav"; nbits=32, compression=WAVE_FORMAT_IEEE_FLOAT)

@bjarthur
Copy link
Contributor Author

ahah, that works. the documentation though says that if the data are floats and nbits is 32 then the output format is single, and makes no mention of the compression format there. perhaps the table needs to be updated?

also, i've uncovered another related error:

julia> tmp=rand(Float32,(10,2))
10x2 Array{Float32,2}:
0.402853 0.359412
0.839331 0.918946
0.37568 0.355417
0.631095 0.914516
0.529367 0.796124
0.771321 0.21159
0.464903 0.874699
0.396011 0.121397
0.149417 0.0536192
0.470153 0.17993

julia> wavwrite(tmp,"foo.wav"; compression=WAVE_FORMAT_IEEE_FLOAT)
ERROR: 16 bits is not supported for WAVE_FORMAT_IEEE_FLOAT.
in error at error.jl:21
in ieee_float_container_type at /Users/arthurb/.julia/WAV/src/WAV.jl:201
in write_ieee_float_samples at /Users/arthurb/.julia/WAV/src/WAV.jl:322
in write_data at /Users/arthurb/.julia/WAV/src/WAV.jl:348
in wavwrite at /Users/arthurb/.julia/WAV/src/WAV.jl:436
in wavwrite at /Users/arthurb/.julia/WAV/src/WAV.jl:442

@dancasimiro
Copy link
Owner

I will look into changing the default nbits value when the compression is set to WAVE_FORMAT_IEEE_FLOAT.

I will also push a change into the documentation, unless you submit a pull request first. You can edit README.md through the github web interface and create a pull request.

dancasimiro added a commit that referenced this issue Apr 6, 2014
Fix behavior to match the documentation.
@dancasimiro
Copy link
Owner

I finally got around to working on this. Let me know if I missed anything.

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

No branches or pull requests

2 participants