- This topic has 7 replies, 3 voices, and was last updated 18 years, 2 months ago by
.
-
Posts
-
Not sure if this is a svn-1372 problem but it’s the first time I noticed it. I have a number of files which are 48 kHz digitizations from LPs saved as flacs. They haved been fine with ssc (I use the perl script) to both iTunes and Soundbridges (m500 and m1000). I have just noticed that on both clients they are playing at 44 kHz. It’s a little subtle – slightly lower frequency and tempo – more dirgelike. The give away however is that the songs cutoff before they end – when the time counter reaches the expected duration of the song – with is ~10% too short when you play 48 kHz samples at 44 kHz. Also, if I play a file from my server using winamp and look at the time where it transitions from intro to vocals (e.g. Fat Lady of Limburgh from Taking Tiger Mountain by Startegy it occurs at 18 sec). Played through mt-daapd (whoops firefly) the transition is 10% later (i.e. 20 sec for the Eno example).
If I do get info in iTunes it lists the song as a 48 kHz wav as it should.
Of course CD rips at 44 kHz are fine which is why I am not sure when this started. I know for sure it has worked for me in the past and the files, and flac version etc haven’t changed since then so it was a mt-daapd change.
PS I’m running on gentoo x86
***I lied – I’m not using the perl transcoding script – I had an old ssc_prog entry in my conf. Instead I was using the ssc-ffmpeg.so plugin. If I switch to ssc-script.so and the old perl script the problem goes away. Looks like a ssc-ffmpeg.so problem – could date back to original implementation of plugin for transcoding
@gordo wrote:
***I lied – I’m not using the perl transcoding script – I had an old ssc_prog entry in my conf. Instead I was using the ssc-ffmpeg.so plugin. If I switch to ssc-script.so and the old perl script the problem goes away. Looks like a ssc-ffmpeg.so problem – could date back to original implementation of plugin for transcoding
Do you have a small sample you could email me?
Hi Ron and Gordo….
I see this thread is a couple of weeks old, but wondered if we ever found anything out about this?? I’ve just experienced the same issue with FLACs encoded from 48KHz WAV’s.
I ripped a set of LPCM tracks from a DVD that I had that were 24Bit/48KHz. Converted these to FLAC and both the FLACs and original WAVs played fine in Winamp. But when I deployed them to my Firefly server (svn-1372) and tried to play in either iTunes or SoundBridge, each track ended prematurely. The track length displayed correctly, but about 3 to 5 seconds was cut off of the end of each track.
I then downsampled all of the WAVs to 44.1KHz 16Bit, reencoded to FLAC, and now they play just fine through Firefly.
Is Firefly having problems with 48KHz sources?
Its a problem with ffmpeg transcoding rather than firefly per se. If you transcode with the perl script or shell script then it is fine at 48 kHz.
@gordo wrote:
Its a problem with ffmpeg transcoding rather than firefly per se. If you transcode with the perl script or shell script then it is fine at 48 kHz.
Ahh yes …. think I understood that, but I just sort of lumped the transcoding and firefly together 🙂
So additional question…. is it possible to implement the script-based transcoding on Windows XP? Think I might have some Perl runtime support hanging around somewhere on the system from when I was still running SlimServer.
How would one use the script method instead of the ffmpeg transcoding??
Thanks
@jtbse wrote:
So additional question…. is it possible to implement the script-based transcoding on Windows XP? Think I might have some Perl runtime support hanging around somewhere on the system from when I was still running SlimServer.
Theoretically, yeah… although it seems that popen doesn’t work right on win32, or there are problems associated with the fact that sockets aren’t *real* fds on win32.
I tried that as the first approach, and it didn’t work so hot. It could be done, but it would likely need a different ssc module that’s completely different than the existing one, using native windows exec functions (CreateProcess?) and dealing with windows files using the native apis (CreateFile, etc).
I think fixing the ffmpeg one would be actually quicker and easier.
— Ron
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.