sfplay~ not working
Maxmsp wont read sound files from disk. In order to play a soundfile, the only way is to use buffer~
Specs:
OS: Windows 10 on a Lenovo L530
MAX 6.1.9 32 bit; MAX 7.2.2 32 bit
In both versions, sfplay~ wont work; the problem is the same whether I use the internal sound card, or an external one..
I am running both MAX versions in compatibility mode with Windows 7.
You won't get any answers withot providing details.
What kind of sound files etc etc
I used to have a custommer who would sometimes phone me and just say "it does not work !"
without even telling me what he was talking about...
Well, actually now sfplay~ does read and play .aiff files, but it seams that it doesn't accept .wav files ...
To make it clear: I am talking about the object in itself, even from the help patch...
OK, som more experimenting...:
Now I used buffer~ to read a .wav file and then write it to the disk in .wav format. When opening this second file, sfplay~ worked as it should. The first file still doesn't work.
I have uploaded the first file (that doesn't work) as "First file.wav" and the second (that does work) as "second file.wav"; I simply can't see how they are different..
Help!
Well it could be that wav file has some specific format which doesn't work in sfplay.
Maybe You could get info about it in some sample editor, and see what it exactly is.
The fact that buffer is able to read ( or maybe import) and save as wave with default
header etc makes it readable to sfplay object.
I remeber similar things happening with aiff files in old days when moving
from Mac OS9 to OSX.
Unfortunately I can't see here the files You tried to upload, to have a look at them.
Maybe the upload failed if they were too big. ( max file esize 512 kb )
THanks for helping, SOURCE AUDIO; I have uploaded the two files on gdrive: https://drive.google.com/folderview?id=0B-u2iHB0oMAyVU1OaEx0UVdUT3c&usp=sharing
If someone could check the files in sfplay that would be awesome, !!
:-)
The first and second Wave Files are having different Header.
The first one is some sort of compressed Wave file.
I don't know if You know much about file header in Audio Files,
it is simply description of various parameters like file kind,
no of channels etc etc followed by Raw sample data.
If You are interested in more infos :
http://soundfile.sapp.org/doc/WaveFormat/
Now I am not really interested in Windows and all the troubles it brings with,
but the shitty media player will allways give you trouble importing files
from CDs or whatever sources, and storing them in all possible shitty formats,
like wma, compressed wave etc, without asking in first place if You want it to be done so.
Buffer in Max can deal with that kind of Wave File, and when you export it
it saves raw Wave File. Sfplay can't do that.
Thanks for your help Source Audio. I have two suspects: one is google drive and the other is adobe audition. I use the latter for editing and the former for storing the audio files. However, the patch I am making should not malfunction when reading sound files from disk, wherever they come from, and the problem is that max doesn't come up with any kind of warning, not even in the max window. So I can't see any way of knowing when the file has not been read properly by sfplay.
I am using a drag-and-drop feature to read sound files in my patch, and since I don't want to switch to buffer - because of a larger consumption of CPU - I have decided to simply use a buffer object as an intermediary, reading and writing the audio file (and emptying the buffer again) before giving sfplay access to it. This way, the audio file doesn't take up space in the patch, - because it doesn't stay in the buffer - and at the same time sfplay can nice and easily read the audio file from disk without any header issues (or whatever the problem was)
:-)
Sure, buffer import/store routine fixes the poblem, but wouldn't it
be better to get Adobe Audition save wave files uncompressed ?
I can't imagine that storing files to Google Drive would change wave file format,
so it must be Adobe Software.
Check the preferences.