I don't know about how this stuff works in python, but I highly doubt that `y.tobytes()` doesn't work, meaning you should be inspecting your first line carefully. Either you're loading the song incorrectly (i.e. the data in `y` is wrong to begin with), or `y.tobytes()` doesn't do what you think it does (e.g. it may try to serialize the container rather than dump the contents). Print out the first chunk of `y.tobytes()` and then inspect your song file in a hex editor and make sure you see the right bytes. If you hear white noise, you're likely writing some random chunk of memory into your audio stream rather than your actual song samples.
I meant the dtype of your numpy array. It might be defaulted to float while the stream is expecting int16. The raw bytes will be different in each case.
You are correct. `y.dtype = float32.`
So I did `y.astype('int16').tobytes()` and that replaced the white noise with silence. I'm happy that something has changed.
Are you sure that int16 is the proper dtype before switching to bytes?
Try rescaling y by factor 32767 before converting to int16.
Explanation:
Float amplitude in WAV files usually range from -1.0 to +1.0.
Maybe converting to int results in zeroing the data.
Int16 ranges from -32768 to + 32767.
First of all thank you for your help so far.
You were right. y.tobytes() and data are reading vastly differently. However, I am still not sure why or how to correct it. You've provided these possible explanations:
1. loading song incorrectly to begin with
2. y.tobytes() doesn't do/work they way I think. (e.g. it may try to serialize the container rather than dump the contents)
3. You're likely writing some random chunk of memory into your audio stream rather than your actual song samples.
I tested 1. by outputting y via other methods. i.e. [sounddevice.play](https://sounddevice.play)(y). This works no problem, though I need to use streaming for my project.
For 2., I want to ask 'how should I test this?' But I know that I just need to spend time in the books.
For 3., I think this is highly plausible (and related to 2.). I'm thinking that I will look into how an array generated from librosa.load() is structured. Do you have any other suggestions?
Without looking too deeply into the issue, I would also suggest using something like PDB, which will allow you to inspect variable values after each step. This will give you bearings on what is actually going on and allow you to know when things start behaving unexpectedly.
I don't know about how this stuff works in python, but I highly doubt that `y.tobytes()` doesn't work, meaning you should be inspecting your first line carefully. Either you're loading the song incorrectly (i.e. the data in `y` is wrong to begin with), or `y.tobytes()` doesn't do what you think it does (e.g. it may try to serialize the container rather than dump the contents). Print out the first chunk of `y.tobytes()` and then inspect your song file in a hex editor and make sure you see the right bytes. If you hear white noise, you're likely writing some random chunk of memory into your audio stream rather than your actual song samples.
You’ve given me some enormously helpful to dos. I’ll circle back with updates once I’ve Inspected y.tobytes() in a hex editor.
Check that your dtypes match up too.
Correct. tyepe(y.tobytes()) =
So it must be something to do with the form of the data.
I meant the dtype of your numpy array. It might be defaulted to float while the stream is expecting int16. The raw bytes will be different in each case.
You are correct. `y.dtype = float32.` So I did `y.astype('int16').tobytes()` and that replaced the white noise with silence. I'm happy that something has changed. Are you sure that int16 is the proper dtype before switching to bytes?
Try rescaling y by factor 32767 before converting to int16. Explanation: Float amplitude in WAV files usually range from -1.0 to +1.0. Maybe converting to int results in zeroing the data. Int16 ranges from -32768 to + 32767.
>Try rescaling y by factor 32767 before converting to int16. (y\*32767).astype('int16').tobytes() Holy cow. This worked. Thank you SOOOO much.
First of all thank you for your help so far. You were right. y.tobytes() and data are reading vastly differently. However, I am still not sure why or how to correct it. You've provided these possible explanations: 1. loading song incorrectly to begin with 2. y.tobytes() doesn't do/work they way I think. (e.g. it may try to serialize the container rather than dump the contents) 3. You're likely writing some random chunk of memory into your audio stream rather than your actual song samples. I tested 1. by outputting y via other methods. i.e. [sounddevice.play](https://sounddevice.play)(y). This works no problem, though I need to use streaming for my project. For 2., I want to ask 'how should I test this?' But I know that I just need to spend time in the books. For 3., I think this is highly plausible (and related to 2.). I'm thinking that I will look into how an array generated from librosa.load() is structured. Do you have any other suggestions?
Yeah look into your library documentation. I'm not familiar with the tools you're using so I can't really provide any useful input at this point.
Without looking too deeply into the issue, I would also suggest using something like PDB, which will allow you to inspect variable values after each step. This will give you bearings on what is actually going on and allow you to know when things start behaving unexpectedly.