sfrecord~/sfinfo~ problem w/multichannel wav files
Mar 28 2013 | 10:52 pm
I put together this demo patch. It creates a 6 channel wav file using sfrecord~ and attempts to get info using sfinfo~. It works fine for aif files but not for wav.
Some clues: The 6ch wav file plays fine in the quicktime player. It opens cleanly in Adobe Audition. If you resave it from Audition sfinfo~ can read it properly.
So there seems to be some incompatibility between the file written by sfrecord~ and reading it with sfinfo~.
Or I could be doing something wrong. Any thoughts?
- Mar 29 2013 | 12:44 amHere's what I get: no channels, no bit depth, no sample rate, crazy numbers for the duration (timecode) - only the filename.(Edit: the duration in ms is inf)The normal sfinfo~ output (for the input file) is given for reference.
- Mar 29 2013 | 9:07 am
- Mar 29 2013 | 12:37 pmHi,the and the objects causes your problems: outputs control values, its outputs are not in the signal domain.Best
- Mar 29 2013 | 1:31 pmThank you both for your help.Patrick: I read that thread (and several others that were related) before posting. That thread is two years old (some of the other threads are older). The last post is a year ago. I thought perhaps there was some newer information. Has Max really not been able to write the industry-standard wav file format for this long?Helmuth: No, that's not the problem. The sig~ and snapshot~ are unnecessary (leftovers from stitching together bits and pieces to create this demo patch) they cancel each other out. If you remove them both same results. As I mention in my second post the actual duration reported by sfinfo~ in ms is "inf". This wouldn't account for all of the other missing information anyway.Here's what I've found: 1) In step 3, when I open the output file with the savedialog object the savedialog requires an uppercase WAVE to force it to output a wav filename. It reports the filename with path out outlet 1 and the filetype out outlet 2. The reported filetype is again uppercase WAVE. I pack the two together and prepend "open" to get: 'open "path/filename" WAVE' and feed that into the sfrecord~ object --- but --- sfrecord requires the filetype argument to be lowercase "wave". My patch was writing AIFF files with a .wav extension. If sfrecord~ doesn't understand the filetype argument it goes to its default filetype. I discovered this by examining the file header. 2) The solution to get it to write wav files was to case convert "WAVE" to "wave". 3) Now it writes wav files that sfinfo~ can understand. 4) Unfortunately ---> they are wav files that nothing else will read.(Edit: one last note, 1 or 2 channels good, 3 or more channels bad.)If I think back over all of the things cycling74 has done over the last several years (Max 5 and 6, Max4Live, gen, 64 bit...) it's astounding that something this fundamental (being able to write industry standard audio files) has gone unfixed.Am I missing something?
- Mar 29 2013 | 2:05 pmHi, everything works fine here with aiff, no problem with filenames etc. I tested up to 6 channels. maybe a problem with wave format? Best
- Mar 29 2013 | 2:33 pmI changed WAVE in wav (lowercase) , tested up to 6 channels, everything works fine here (MAX 6.08) Mac 10.5.8)Best
- Mar 29 2013 | 4:21 pmHelmuth, thank you, however,1) as I said in my initial post aif files are correctly formed, wav files are not.2) Changing to "wav" does not work. Look at what is coming out of the second outlet. only "AIFF" and "WAVE" work correctly. Other inputs return nothing out the second outlet and therefore sfrecord~ defaults to writing AIFF files (no matter what the file extension is or whether there is an extension at all). My guess is that you are creating AIFF files and that is why they seem to work. They're not WAVE files.
- Mar 31 2013 | 9:20 amHi, here the info of my created wav files. I do not think that they are "disguised" aiff files, but may be I am wrong... Effectively if you may state this fact, (as you are mentioning also in your second thread), it would be interesting to contact directly cycling support. Best
- Mar 31 2013 | 5:55 pmHi Helmuth,Thanks again, you can use a hex editor (there are plenty of them out there - i like "Hex Fiend" it's open source and free)but the easiest way to check this is to open your audio file with a text editor (like TextEdit) and look at the first line.let me know what you find.
- Mar 31 2013 | 9:37 pmHi, when I tryed to play again the presumed wave file of last testing, I got a surprise: error message in max window: error opening test_04.wav, err -1 sfplay~: can't open wave file test_04.wav.I opened the file following your advise with a text editor => I got like you the same result : FORMAT AIFFCOMM
- Mar 31 2013 | 9:41 pmSo I tryed to record various different sound files to investigate again, nothing worked. Finally I found out why I assumed in my prior tests that records properly wav files: As I was using in my prior testing only one and the same soundfile, the file I was listening to was not the recent created wav file one, but the most recent played aif file hold in memory by a sfplay I used to test the files !! Mind the gap ;>) !!Actually, no wav file was created! (Strangely, when I used , and not WAVE, as fileformat, I got a correct file length, but the file created was a textfile) When I used WAVE, the file lenght output of info~ sent out a , what creats the strange numbers out of the < sprintf> part in your patch.So, probably you are right. it would be interesting to have a feedback from cycling support. You should contact them.Bestlittle ps: in my sense the is redundant in your patch.