drmatt wrote:
> Flac encoders have changed over the years (though the files themselves
> are supposed to be the same format). Presumably the file plays fine if
> you decode it to wav/aiff and then re- encode to flac using a known
> encoder?
>
> In general no differences in compression methodolo
If you have a LMS installation then you can use the iHeart Radio plugin
https://forums.slimdevices.com/showthread.php?108466-ANNOUNCE-iHeartRadio-to-play-US-live-iHeart-radio-stations
bpa's Profile: http://forums.slimdev
lumina02 wrote:
> Dear all,
>
> I have proudly owned the Squeezebox Touch since December 2011, when I
> bought it new.
>
> I have seen a steady decline of mostly US- Commercial Radio Stations
> who simutaneously offered a stream through the "Logitec Network" (I
> guess).
> Many of those Radi
DBart wrote:
> Yes - just bizarre it's with one file (well, 5 from the same recording)
> :-)
>
> Would there be a way that a studio, in this case ChannelClassics, would
> encode a file that would cause this to happen? All other 192 files were
> purchased from HDTracks and none of those exhibit
Yes I'm aware of aiff. It was the default audio file format on my SGI O2
... The implication of what's being discussed is that there is a *data*
dependency for this file. Something, very odd, about the audio data
itself is causing the Touch to require buffering whether it's played as
aiff (i.e. s
Its a real mystery. Im very curious. Can the OP post the track
somewhere so that others can test it on a different system. Dropbox,
etc.
p.s. I hope this is an enjoyable track, as much of a headache as its
been. 😳
*Home:* VBA 4TB (2.4)>LMS 7.9.1>Transporter, Touch, Boom, Radio
(ethernet)
*
Also. You could always just downsample it to 16/44 and be done with
it.. :)
-Transcoded from Matt's brain by Tapatalk-
--
Hardware: 3x Touch, 1x Radio, 2x Receivers, 1 HP Microserver NAS with
Debian+LMS 7.9.0
Music: ~1300 CDs, as 450 GB of 16/44k FLACs. No less than 3x 24/44k
albums..
--
:rolleyes: I recall he may have tested with 24/96 and it worked fine.
p.s. if I have a choice on downloads I always buy 16/44.1. If not Ill
always choose 24/96 if I have a choice. Works with mt transporter and
touch. And its the *mastering* that matters anyhow.
drmatt wrote:
> Also. You co
Silly question: has the OP decoded the file and re-ncoded it with FLAC,
compression level 0. If not I think that would be useful.
Touch, Meridian G92, Bryston B4 SST2, PMC OB1i speakers, HP Proliant
Microserver/Ubuntu, PC/Windows 7, iPad 4, iPeng, Squeezepad.
--
JohnB wrote:
> Silly question: has the OP decoded the file and re-ncoded it with FLAC,
> compression level 0. If not I think that would be useful.
Yes and remove metadata and encoded into AIFF - every time the file
doesn't play - rebuffering
---
Is the file being transcoded by lms? Delays during transcoding will also
manifest as client buffering, iirc.
-Transcoded from Matt's brain by Tapatalk-
--
Hardware: 3x Touch, 1x Radio, 2x Receivers, 1 HP Microserver NAS with
Debian+LMS 7.9.0
Music: ~1300 CDs, as 450 GB of 16/44k FLACs. No le
drmatt wrote:
> Is the file being transcoded by lms? Delays during transcoding will also
> manifest as client buffering, iirc.
I think the OP should at least check it out thge possibility by enabling
logging player.source to INFO and see if LMS does something strange to
the file.
However - why
AIFF can be thought of as being WAV with knobs on.
WAV capable of carrying metadata, something that WAV itself has
difficulty with.
So the files are bigger from the off.
They're both PCM, and both have bandwidth hogging issues, which if not
met causes rebuffering.
The reason why FLAC was settled
Stratmangler wrote:
> AIFF can be thought of as being WAV with knobs on.
> WAV capable of carrying metadata, something that WAV itself has
> difficulty with.
> So the files are bigger from the off.
> They're both PCM, and both have bandwidth hogging issues, which if not
> met causes rebuffering.
14 matches
Mail list logo
