BUG: read tries to handle 20-bit WAV files but shouldn't

[endolith]

Audition can save WAV files as "24-bit packed int (type 1, 20-bit)" format where each sample is 3 bytes and BitsPerSample = 0x14 = 20. SciPy tries to open it and interprets it as 16-bit and it's all screwed up. Changed the handling to only accept bits per sample that align with numpy int types.

I guess it would be better if it read the byte lengths from numpy itself instead of a hardcoded list?

Though better yet would be to read any bit depth of file and store it as the next-highest numpy int type.

(And should also have a norm=True or something option that converts every type to normalized floating point from -1 to +1 so you don't have to do that yourself, same as scikits.audiolab.)

[codecov-io]

@@            master   #5990   diff @@
======================================
  Files          238     238       
  Stmts        43757   43757       
  Branches      8218    8218       
  Methods          0       0       
======================================
  Hit          34182   34182       
  Partial       2604    2604       
  Missed        6971    6971       

Review entire Coverage Diff as of ba6666c

Powered by Codecov. Updated on successful CI builds.

[larsoner]

Though better yet would be to read any bit depth of file and store it as the next-highest numpy int type.

Agreed.

And should also have a norm=True or something option that converts every type to normalized floating point from -1 to +1 so you don't have to do that yourself, same as scikits.audiolab

By normalizing by MAX_INT for the appropriate type? Agreed.

PRs welcome when you get time.

[larsoner]

I think the manual list is okay for now. Hopefully you can make it better soon :)

Good to merge from your end?

[endolith]

By normalizing by MAX_INT for the appropriate type? Agreed.

Actually normalizing to BitsPerSample from the headers, in case it's not a multiple of 8, and shifting from unsigned for BitsPerSample from 1 to 8.

and if it doesn't normalize, it should return the bit depth as well as fs and data.

Good to merge from your end?

yes

[larsoner]

and if it doesn't normalize, it should return the bit depth as well as fs and data.

This one would be tougher because it would be a backward-incompatible change, but I suppose you could add a return_depth=False (by default) argument.

[larsoner]

Thanks @endolith

[endolith]

This one would be tougher because it would be a backward-incompatible change, but I suppose you could add a return_depth=False (by default) argument.

Actually maybe that should be a separate function? This one is only for converting to exact equivalent dtypes, when possible?

[larsoner]

This one is only for converting to exact equivalent dtypes, when possible?

A normalize=True could determine which dtypes can be read in. Can't decide if that's too magical, though. Seems like it would be okay if it's documented properly.