Bugzilla – Bug 14783
WAV -> FLAC on OSX fails: SOX error
Last modified: 2009-10-22 11:23:29 UTC
Trying to play a WAV file on OSX results in silence with the following error message in the logs: flc /Users/mh/Documents/workspace/7.4/server/Bin/darwin/sox formats: can't open input `-': WAVE: RIFF header not found flc /Users/mh/Documents/workspace/7.4/server/Bin/darwin/sox formats: can't open input `-': WAVE: RIFF header not found
I wonder if you have a bad WAV file. I can play WAV -> FLAC just fine.
Created attachment 6129 [details] --debug player.source=debug Andy - I took a CD, ripped it to WAV using EAC's default settings, tried to play it on the Mac. Failure. I've tested with all wav files I have, plus that newly ripped file. It always fails. Did you compile sox on SL? Maybe there's a difference?
Andy: did you try it with OSX 10.5 or 10.6?
10.6, but that shouldn't matter.
Alan, did you have a look at the log?
QA to continue to investigate
I am seeing this as well, investigating further.
My log looks pretty much the same as Michael's. Disabling WAV FLAC and just using WAV WAV does work by the way. Tested on the following: Version: 7.4.0 - r28667 @ Mon Sep 28 09:30:43 PDT 2009 Hostname: smsg4pb.local IP: 172.19.120.81 HTTP Port: 9000 OS: Mac OS X 10.4.11 (8S165) - EN - utf8 Platform: ppc Perl Version: 5.8.6 - darwin-thread-multi-2level MySQL Version: 5.0.22-standard Total Players Recognized: 1
This is also broken on a system running Mac OS X 10.5.7 but is working for me on a system running Mac OS X 10.6.1. So this looks like a SOX compiling issue.
sox is unchanged since 7.3, so was this also broken there?
7.3.3 works for me. Looking at File Types for 7.3.3 I see WAV FLAC > FLAC MP3 > disabled WAV > Native in 7.4.0/1 I see WAV FLAC > SOX MP3 > disabled WAV > PCM
Ah, OK, here are the changes made to AIFF -> FLAC and WAV -> FLAC in 7.4: aif flc * * - # FT:{START=--skip=%t}U:{END=--until=%v} - [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ - + # FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d} + [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ - + wav flc * * - # FT:{START=--skip=%t}U:{END=--until=%v} - [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ + # IFD:{RESAMPLE=-r %d} + [sox] -q -t wav $FILE$ -t flac -C 0 $RESAMPLE$ - Maybe we need to revert it? Still doesn't explain why it works for me.
Andy, perhaps you are right about it not being a sox issue. sox seems to run fine on all my mac systems. Not sure what else it could be though. Alan do you have any ideas? I will attach two more logs to this bug in a moment.
Created attachment 6172 [details] log of wav playing as flac via sox successfully on Mac OS X 10.6
Created attachment 6173 [details] log of wav playing as flac via sox failing on Mac OS X 10.5
Ah, maybe this is the trigger: + # IFD:{RESAMPLE=-r %d} + [sox] -q -t wav $FILE$ -t flac -C 0 $RESAMPLE$ - Perhaps the 'I' in the capabilities line is triggering the problem. Steven, can you try removing it and testing? Perhaps sox on some platforms/os-versions cannot read the WAV (RIFF) header from stdin. That would correspond to the error message in the original description. This cannot be the real fix because removing 'I' will remove the ability to seek in WAV files.
> Perhaps the 'I' in the capabilities line is triggering the problem. Confirmed: it's playing fine without the I.
So the question is why can sox read the header from stdin fine on 10.6.1 but fails on 10.5.7?
Michael, any chance you can try to debug that (I don't have a Mac)?
> Michael, any chance you can try to debug that (I don't have a Mac)? What do you want me to try?
Run sox in a debugger under 10.5 to find out why it fails to read the RIFF header when reading a WAV file from stdin.
== Auto-comment from SVN commit #28947 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28947 == Fixed bug 14783, when playing a local file we need to always seek to the right point, even if that point is 0. Audio::Scan may seek into the file on the same filehandle causing the start point to be wrong, for some reason this only appeared to affect OSX 10.5
This bug has been marked as fixed in the 7.4.1 release version of SqueezeBox Server! Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.