Re: [SlimDevices: Unix] piCorePlayer Documentation
Added "'Build a simple LMS server' (https://docs.picoreplayer.org/projects/build-simple-lms-server/)" project. Considering this should be the simple how-to, I'd recommend to always use the full SD card size. The warning about the partition size is already too complicated for a simple instruction set. Unfortunately removing that warning will get rid of the only color spot on the page :-) -- Michael ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
mherger wrote: > > > I'm sorry... I probably did too much testing and double checking and > eventually left in the wrong rule... a new build is on its way. > > -- > > Michael I know the feeling :) amey01's Profile: http://forums.slimdevices.com/member.php?userid=11274 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCorePlayer Documentation
Added "'Build a simple LMS server' (https://docs.picoreplayer.org/projects/build-simple-lms-server/)" project. This project is what I do to build my LMS server. I will recheck the process and add a few more notes the next time I build it. My LMS servers are quite generic, no NAS, no network shares and take only 20 minutes to build from scratch. Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403 View this thread: http://forums.slimdevices.com/showthread.php?t=112996 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCorePlayer Documentation
Added '\"Standalone piCorePlayer\"' (https://docs.picoreplayer.org/projects/standalone-pcp/) project. I did this "as a project" quite a few months ago but never got around to publishing the notes I took. It probably still needs a triple check but good enough for now. Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403 View this thread: http://forums.slimdevices.com/showthread.php?t=112996 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
I checked the replaced convert.conf file and it still had "IFT" listed for flc>flc. I took out "I" and all is working fine once again. I'm sorry... I probably did too much testing and double checking and eventually left in the wrong rule... a new build is on its way. -- Michael ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
mherger wrote: > > Thanks for the help all (and especially bpa) - Let me know if I can > help > > more - testing or experimenting with anything. Happy to contribute to > > any better solution. > > Please give the next 8.0.1 nightly build a try. Should be up in a few > hours. > > -- > > Michael Did not work. I checked the replaced convert.conf file and it still had "IFT" listed for flc>flc. I took out "I" and all is working fine once again. amey01's Profile: http://forums.slimdevices.com/member.php?userid=11274 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
bpa wrote: > Will it work with Flac 24bit/192kHz flac file with a cue sheet being > resampled to play on a 96kHz player ? AFAIK if you use raw - you will > lose sample size. It looks like you assume 16 bit sample size ? > I think Michael added a %C channel count a few years ago, maybe time to > add sample size to the transcoding helper. Yes, this is where I was aiming at, otherwise we'd have to limit to 16 bits and probably make a separated "I" rule to limit collateral damages (you can have different rules now for different sources, that one thing I've added in 8.0) but I feel some will not like it (I personally don't mind but that's a battle I'm not interested taking). It's not there in the current TranscodingHelper.pm but it's probably not complicated to add (just need to find a free letter :)) if you and Michael think it is worth LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
philippe_44 wrote: > So far, it works if I use it a general rule (flc flc * * ) whether there > is a seek or not (careful, when used as a general rule, $RESAMPLE$ is > not defined, so must force -r x for test). But I need to verify that > more and find a solution for the sample size as well Will it work with Flac 24bit/192kHz flac file with a cue sheet being resampled to play on a 96kHz player ? AFAIK if you use raw - you will lose sample size. It looks like you assume 16 bit sample size ? I think Michael added a %C channel count a few years ago, maybe time to add sample size to the transcoding helper. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
bpa wrote:
> I think I understand what you're saying. I assumed that Flac was trying
> to do a Linux "seek" on the input file to implement "skip" and it
> couldn't do a "seek" on stdin piped input.
I missed something so my HTTP comment was incorrect (I thought the OP
was talking about some streams) but I don't think it changes the
conclusion. The following rule does not work
Code:
flc flc transcode *
# IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -C 0
$RESAMPLE$ -
AFAIK, when using a rule from stdin, LMS does not expect the transcoders
to do anything wrt seeking. It does the seek on behalf and then send the
remaining bytes to the transcoder. That applies wherever stdin is
generated from (remote or local). But a rule that allows "I" and uses
flac will start the "flac" process at the seeked position (if any). So
if there is no seek, flac will see a STREAMINFO header and will generate
a proper wav header that pleases sox. But as soon as there is a seek,
that header disappears and especially sample_count is unknown, so the
wav header is absent or incorrect and sox fails. I don't use cuesheets,
but I think it's a seek for the 2nd track, which would match the OP's
experience.
I think that if we want to use flac with seek, we have to use raw pcm
for sox input, so a rule like
Code:
flc flc transcode *
# IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[flac] -dcs $START$ $END$ --force-raw-format --sign=signed
--endian=little -- - | [sox] -q -t raw --encoding signed-integer -b 16
$RESAMPLE$ -c $CHANNELS$ -L - -t flac -C 0 -
So far, it works if I use it a general rule (flc flc * * ) whether there
is a seek or not (careful, when used as a general rule, $RESAMPLE$ is
not defined, so must force -r x for test). But I need to verify that
more and find a solution for the sample size as well
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2,
Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5,
Riva 1 & 3
philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261
View this thread: http://forums.slimdevices.com/showthread.php?t=113308
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
philippe_44 wrote: > I looked a bit more and had to refresh my memory. > > The issue seems to me that when we use "I" and seek, then LMS does a > HTTP range request to reach the guessed offset (I worked on that flac > header parsing & building for 8.0) so the flac decoder does not have a > STREAMINFO header, it's just streamed flac. > > In that case, it does not seem to rebuild a proper WAV header and as > consequence sox fails to resample. This is what I observe in the > conversion log. I feel it can be fixable by either forcing flac decoding > to build a proper header or by using raw and giving sox the raw > parameters I think I understand what you're saying. I assumed that Flac was trying to do a Linux "seek" on the input file to implement "skip" and it couldn't do a "seek" on stdin piped input. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
mherger wrote: > > Thanks for the help all (and especially bpa) - Let me know if I can > help > > more - testing or experimenting with anything. Happy to contribute to > > any better solution. > > Please give the next 8.0.1 nightly build a try. Should be up in a few > hours. > > -- > > Michael No probs.will try later today. amey01's Profile: http://forums.slimdevices.com/member.php?userid=11274 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
bpa wrote: > I'm not sure if I made the subtly of the issue clear. The problem > relates to two very specific limited use cases - Cue/Flac & Tidal/Flac. > > The flac command does not support the "--skip" option if input is from > stdin. > > With flac/cue files, if no resampling is required, LMS will process flac > file and skip to right point and direct stream to player > With flac/cue file, transcoding with flac & sox will be used if > resampling is required. I think the "--skip" option will appear if not > playing from 0. The flac command with "--skip" will fail if input is > from stdin. > > Creating a tdlflc would solve the current issue (i.e. IFT for Tidal and > FT for cue/flac), > > The Tidal problem affects a few high compression Tidal track causing > stuttering on ip3k players. > > I believe Tidal can supply 96kHz tracks (albeit with MQA). > If LMS were to play these track to a SB3 - resampling would be required. > > If a user were then to ffwd within the track I think the same issues > with flac/cue would occur. > Is this too specific a user case to worry about ? I looked a bit more and had to refresh my memory. The issue seems to me that when we use "I" and seek, then LMS does a HTTP range request to reach the guessed offset (I worked on that flac header parsing & building for 8.0) so the flac decoder does not have a STREAMINFO header, it's just streamed flac. In that case, it does not seem to rebuild a proper WAV header and as consequence sox fails to resample. This is what I observe in the conversion log. I feel it can be fixable by either forcing flac decoding to build a proper header or by using raw and giving sox the raw parameters LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
Thanks for the help all (and especially bpa) - Let me know if I can help more - testing or experimenting with anything. Happy to contribute to any better solution. Please give the next 8.0.1 nightly build a try. Should be up in a few hours. -- Michael ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCorePlayer Documentation
- 'Add section on hardware recommendation' (https://gitlab.com/piCorePlayer/pCP-docs/-/issues/3) - 'Add how-to attach a network drive' (https://gitlab.com/piCorePlayer/pCP-docs/-/issues/4) Did you forget to push these changes? I don't see them in git. -- Michael ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
Thanks for the help all (and especially bpa) - Let me know if I can help more - testing or experimenting with anything. Happy to contribute to any better solution. amey01's Profile: http://forums.slimdevices.com/member.php?userid=11274 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCorePlayer Documentation
Hi Jon T, Thanks for your feedback. I have added a couple of issues on git: - 'Add section on hardware recommendation' (https://gitlab.com/piCorePlayer/pCP-docs/-/issues/3) - 'Add how-to attach a network drive' (https://gitlab.com/piCorePlayer/pCP-docs/-/issues/4) Your requests are interesting for a couple of reasons: 1) From my personal experience, you can use any RPi you want. So I don't have any recommendation. I used a RPi1B with 256MB memory for my LMS hardware for years! 2) I don't use a NAS or mount network shares so I haven't documented it. There is a few instructions for SAMBA in the 'Add a USB hard drive and setup SAMBA' (https://docs.picoreplayer.org/how-to/add_usb_hdd/) How-to. So your requests have highlighted that the documentation will have a bias towards the limited topics I know and use. :D regards Greg Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403 View this thread: http://forums.slimdevices.com/showthread.php?t=112996 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCorePlayer Documentation
Hello, I took a look at the new documentation pages. Much easier to read! Some addition suggestions: 1) A hardware requirements page. I'm a piCorePlayer noob and could use guidance on which Pi to buy (3B+? 4? and how much RAM?) and how big an SD card to buy. I was able to find recommendations from users scattered throughout various forum posts, but having official recommendations in one place would be very helpful. Please make any distinctions between recommended configurations for a) player only b) LMS only c) both player and LMS. 2) How to mount NAS and/or Windows Server shares containing music and playlists. I seem to recall the old documentation had a section on this, but can't seem to find its new documentation equivalent. The new docs have how to attach a local USB drive and share that on the network, but not how to consume an existing share. Thanks for the good work! Jon T. Jon T's Profile: http://forums.slimdevices.com/member.php?userid=4 View this thread: http://forums.slimdevices.com/showthread.php?t=112996 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] could this be a Squeezebox player if pCP will install and work?
Over time I've had two of my SB remotes die. I wish I could find replacements easily. I did order one for the Boom from China, but that didn't actually ship. At the moment I have exactly the needed number of remotes for the car (pi/pCP), basement (pi/pCP) and main system(Transporter). The OSMC remote works somewhat, out of the box, but it lacks the great setup of the original SB remotes. The original remotes were perfect for the SB's and the pCP. Well thought out and logical lay out. As for following the documentation for modifying or making a new remote work with pCP...whew. I've started down that road a few times. It's beyond me. I'll just keep praying my SB remotes last longer than I do. Working so far :-) Paul Webster wrote: > I expect that the challenge for the pCP team would be that there are a > lot of remotes out there. > They have documented the basics for how to get a 3rd-party remote to > control things. > I guess that one route would be to have some sort of tool that worked > like a universal remote interpreter and allowed the user to teach pCP > the signals from any given remote and have the tool write out all of the > files (and optionally share them to make it easy for someone else with > the same remote). > Would be a lot of work when I expect that most here have genuine > Squeezebox remotes or programmable ones that can emulate one. Howard Passman's Profile: http://forums.slimdevices.com/member.php?userid=16674 View this thread: http://forums.slimdevices.com/showthread.php?t=113320 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] could this be a Squeezebox player if pCP will install and work?
Howard Passman wrote: > That is one ugly remote :-) And I'm guessing it will only partially > work with piCorePlayer. That's where I would get lost and pCP developers > don't seem to be interested in integrating a few other remotes in to the > package. > I expect that the challenge for the pCP team would be that there are a lot of remotes out there. They have documented the basics for how to get a 3rd-party remote to control things. I guess that one route would be to have some sort of tool that worked like a universal remote interpreter and allowed the user to teach pCP the signals from any given remote and have the tool write out all of the files (and optionally share them to make it easy for someone else with the same remote). Would be a lot of work when I expect that most here have genuine Squeezebox remotes or programmable ones that can emulate one. Paul Webster http://dabdig.blogspot.com author of \"now playing\" plugins covering radio france (fip etc), kcrw, supla finland, abc australia, cbc/radio-canada and rte ireland Paul Webster's Profile: http://forums.slimdevices.com/member.php?userid=105 View this thread: http://forums.slimdevices.com/showthread.php?t=113320 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] could this be a Squeezebox player if pCP will install and work?
Howard Passman wrote: > That is one ugly remote :-) And I'm guessing it will only partially > work with piCorePlayer. That's where I would get lost and pCP developers > don't seem to be interested in integrating a few other remotes in to the > package. > > Definitely let us know your opinion of the DAC especially relative to > some of the other decent DAC's out there. > > Howard Ha ha, yes, I won't be bothering with the remote, it'll stay in the box in case I need to sell the whole thing on. ;) *Server - LMS 8.0.1 *Pi4B 4GB/Flirc case/pCP v7.0.0b6 - 74K library, playlists & LMS cache on SSD (ntfs) *Study -* Pi3B/pCP 7.0.0b6/pi screen/Allo Boss DAC Ruark MR1 Mk2 *Lounge* - Pi2/pCP 6.0.0 > HiFiBerry DIGI+ > AudioEngine DAC1 > AVI DM5 *Garage* - Squeezebox Boom + Fostex sub *Dining Room* - Pi3B/Bluetooth/Echo Show 8 *Spares* - 2xTouch, 1xSB Radio. 1xSB3, 6xRPi kidstypike's Profile: http://forums.slimdevices.com/member.php?userid=10436 View this thread: http://forums.slimdevices.com/showthread.php?t=113320 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] could this be a Squeezebox player if pCP will install and work?
That is one ugly remote :-) And I'm guessing it will only partially work with piCorePlayer. That's where I would get lost and pCP developers don't seem to be interested in integrating a few other remotes in to the package. Definitely let us know your opinion of the DAC especially relative to some of the other decent DAC's out there. Howard Howard Passman's Profile: http://forums.slimdevices.com/member.php?userid=16674 View this thread: http://forums.slimdevices.com/showthread.php?t=113320 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
The only "flc flc transcode" workaround I can find for "IFT" with "skip" uses ffmpeg to skip and resample but then it needs flac to re-encode into Flac. Not a good solution. I think tdlflc provides the required flexibility. As a side note - I noticed that WebUI Settings/Info/Filetypes does not show any of the "transcode" rules. Not sure if we need to - no way to confim a custom "transcode" setting except by running a test with logging. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
philippe_44 wrote:
> I was thinking more about differences between variable and fixed block
> size which can be detected in STREAMINFO header. So far, it seems that
> almost all flac are coded with fixed block but I was wondering is higher
> compression level would not trigger use of variable block which then
> cause the problem on older devices. We can now parse such header so we'd
> know and could use different rules.
There you know more than I do. But we don't even exactly know what is
causing the stuttering, as most tracks on TIDAL would play just fine.
philippe_44 wrote:
> About rules, would something like "flc flc boom *" (e.g.) work for Boom
> only players and do the trick?
You're actually right! I was mislead by this comment in convert.conf:
Code:
# : currently slimp3, squeezebox, or *.
# The * is a wildcard that matches all device
# types.
But the problem is that the default rules can't be modified to do
transcoding, as this seems to break the CUE sheet & transcoding use
case. With the custom formatOverride OTOH we can have the rules for
TIDAL only, thus not interfering with CUE sheets. And with the above
player type rules I can create this, which seems to be doing the job:
Code:
tdlflc mp3 * *
# IFB:{BITRATE=--abr
%B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
[flac] -dcs $START$ $END$ -- $FILE$ | [lame] --silent -q $QUALITY$
$RESAMPLE$ $BITRATE$ - -
tdlflc pcm * *
# IFT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=little --sign=signed $START$
$END$ -- $FILE$
tdlflc aif * *
# IFT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=big --sign=signed $START$ $END$
-- $FILE$
# no native FLAC straming for ip3k, as some tracks stutter on original
hardware
tdlflc flc squeezeplay *
-
I know, it's disabling flac -> flac for TIDAL on ip3k. But the previous
rule using sox would break seeking...
Michael
"It doesn't work - what shall I do?" - "Please check your server.log
and/or scanner.log file!"
(LMS: Settings/Information)
mherger's Profile: http://forums.slimdevices.com/member.php?userid=50
View this thread: http://forums.slimdevices.com/showthread.php?t=113308
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
I'm not sure if I made the subtly of the issue clear. The problem relates to two very specific limited use cases - Cue/Flac & Tidal/Flac. The flac command does not support the "--skip" option if input is from stdin. With flac/cue files, if no resampling is required, LMS will process flac file and skip to right point and direct stream to player With flac/cue file, transcoding with flac & sox will be used if resampling is required. I think the "--skip" option will appear if not playing from 0. The flac command with "--skip" will fail if input is from stdin. Creating a tdlflc would solve the current issue (i.e. IFT for Tidal and FT for cue/flac), The Tidal problem affects a few high compression Tidal track causing stuttering on ip3k players. I believe Tidal can supply 96kHz tracks (albeit with MQA). If LMS were to play these track to a SB3 - resampling would be required. If a user were then to ffwd within the track I think the same issues with flac/cue would occur. Is this too specific a user case to worry about ? bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
amey01 wrote: > On account of this, I have updated the thread title so that it can > easily be found by others: > > * Issue with .cue. (LMS 8.0 FLAC Transcoding Issue) * That's good. Just to clarify. The 6.0.0 player works because it has different DAC *hardware* which does not require resampling and so no transcoding. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
mherger wrote: > > Couldn't the problem happen with any flac file, as long as some flac > > compression mode is being used? > > That's correct. But if it's your own, you got the freedom to re-encode > it. > > > Maybe we could detect that level? > > Unfortunately this seems not to be possible. I googled around for it, > but all I've found was that this wasn't possible. > > > Also, I don't fully remember the problem, but @bpa, doesn't that only > > happens with Boom and some models, right? If it does, could we make a > > transcode rule that only applies to these models? > > Yes, I believe it's ip3k only. There seems to be some logic to limit > certain rules to some players only. But TBH. I haven't figured it out > yet. > > My suggestion really is a band aid to get TIDAL working without breaking > > other stuff. It actually doesn't really work... seeking with flac -> > flac transcoding doesn't work. My latest custom-convert.conf would > simply disable flac->flac and only transcode to PCM/AIF, as that seems > to do the trick, without breaking seeking. > > -- > > Michael I was thinking more about differences between variable and fixed block size which can be detected in STREAMINFO header. So far, it seems that almost all flac are coded with fixed block but I was wondering is higher compression level would not trigger use of variable block which then cause the problem on older devices. We can now parse such header so we'd know and could use different rules. About rules, would something like "flc flc boom *" (e.g.) work for Boom only players and do the trick? LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=113308 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
Couldn't the problem happen with any flac file, as long as some flac compression mode is being used? That's correct. But if it's your own, you got the freedom to re-encode it. Maybe we could detect that level? Unfortunately this seems not to be possible. I googled around for it, but all I've found was that this wasn't possible. Also, I don't fully remember the problem, but @bpa, doesn't that only happens with Boom and some models, right? If it does, could we make a transcode rule that only applies to these models? Yes, I believe it's ip3k only. There seems to be some logic to limit certain rules to some players only. But TBH. I haven't figured it out yet. My suggestion really is a band aid to get TIDAL working without breaking other stuff. It actually doesn't really work... seeking with flac -> flac transcoding doesn't work. My latest custom-convert.conf would simply disable flac->flac and only transcode to PCM/AIF, as that seems to do the trick, without breaking seeking. -- Michael ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] PCP 6.1.0 - Issue with .cue. (LMS 8.0)
mherger wrote:
> @bpa - would the following fix the issue?
>
> >
Code:
> > diff --git a/Slim/Plugin/WiMP/ProtocolHandler.pm
b/Slim/Plugin/WiMP/ProtocolHandler.pm
> index 509de4516..d952e3c88 100644
> --- a/Slim/Plugin/WiMP/ProtocolHandler.pm
> +++ b/Slim/Plugin/WiMP/ProtocolHandler.pm
> @@ -40,6 +40,15 @@ sub getFormatForURL {
> return $format;
> }
>
> +sub formatOverride {
> + my ($class, $song) = @_;
> + my $format = Slim::Music::Info::contentType($song->currentTrack);
> +
> + return 'tdlflc' if $format eq 'flc';
> + return $format;
> +}
> +
> # default buffer 3 seconds of 256kbps MP3/768kbps FLAC audio
> my %bufferSecs = (
> flac => 80,
> diff --git a/Slim/Plugin/WiMP/custom-convert.conf
b/Slim/Plugin/WiMP/custom-convert.conf
> new file mode 100644
> index 0..97d7ff763
> --- /dev/null
> +++ b/Slim/Plugin/WiMP/custom-convert.conf
> @@ -0,0 +1,19 @@
> +
> +tdlflc mp3 * *
> + # IFB:{BITRATE=--abr
%B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
> + [flac] -dcs $START$ $END$ -- $FILE$ | [lame] --silent -q $QUALITY$
$RESAMPLE$ $BITRATE$ - -
> +
> +tdlflc pcm * *
> + # IFT:{START=--skip=%t}U:{END=--until=%v}
> + [flac] -dcs --force-raw-format --endian=little --sign=signed $START$
$END$ -- $FILE$
> +
> +tdlflc aif * *
> + # IFT:{START=--skip=%t}U:{END=--until=%v}
> + [flac] -dcs --force-raw-format --endian=big --sign=signed $START$ $END$
-- $FILE$
> +
> +tdlflc flc * *
> + -
> +
> +tdlflc flc transcode *
> + # IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
> + [flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -C 0
$RESAMPLE$ -
> diff --git a/convert.conf b/convert.conf
> index 90748daa2..1c0739875 100644
> --- a/convert.conf
> +++ b/convert.conf
> @@ -357,7 +357,7 @@ mp3 mp3 transcode *
> [lame] --silent -q $QUALITY$ $BITRATE$ $RESAMPLE$ --mp3input $FILE$ -
>
> flc flc transcode *
> - # IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
> + # FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
> [flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -C 0
$RESAMPLE$ -
>
> # This example transcodes MP3s to MP3s, if the target machine has the
>
> >
>
> What this does is it defines a custom format called "tdlflc". Only
> this should transcode on stdin (IFT), but not regular flac.
Couldn't the problem happen with any flac file, as long as some flac
compression mode is being used? Maybe we could detect that level?
Also, I don't fully remember the problem, but @bpa, doesn't that only
happens with Boom and some models, right? If it does, could we make a
transcode rule that only applies to these models?
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2,
Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5,
Riva 1 & 3
philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261
View this thread: http://forums.slimdevices.com/showthread.php?t=113308
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
