PasTim wrote:
> My limited understanding is that the 3 bytes can be in a different
> order, depending on the device. In the wrong order you get noise. So
> to be able to suit all devices you need to support different 'endian'
> options. See this from the sox 'man':
>
>
> -L, --endian little
> -B, --endian big
> -x, --endian swap
> These options specify whether the byte-order of the audio data is,
> respectively, 'little endian', 'big endian', or the opposite to that of
> the system on which SoX is being used. Endianness applies only to data
> encoded as signed or unsigned integers of 16 or more bits. It is often
> necessary to specify one of these options for headerless files, and
> sometimes necessary for (otherwise) self-describing files. A given
> endian-setting option may be ignored for an input file whose header
> contains a specific endianness identifier, or for an output file that is
> actually an audio device.
> N.B. Unlike normal format characteristics, the endianness (byte, nibble,
> & bit ordering) of the input file is not automatically used for the
> output file; so, for example, when the following is run on a
> little-endian system:
> sox -B audio.s2 trimmed.s2 trim 2
> trimmed.s2 will be created as little-endian;
> sox -B audio.s2 -B trimmed.s2 trim 2
> must be used to preserve big-endianness in the output file.
> The -V option can be used to check the selected orderings.
I managed to get a custom-convert to work for this, albeit in a limited
way. The entry I made was:
Code:
--------------------
flc pcm * 00:04:20:22:70:65
# FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[sox] -q -t flac $FILE$ -t wav -b 24 -B --buffer 65536 --multi-threaded -C 0
$RESAMPLE$ - gain -h rate -v -I -t -b 90.7 192000
--------------------
That worked for 16/44100, 24/9600 and 24/192000. I had to resample
16/44100 up before it would work without noise. I'd have preferred not
to use 192000 (not a multiple), and using C-3PO would have more
flexibility.
Can I suggest that you could add 2 features that allow additional input
sox parameters and additional output parameters - in my case I'd add -B
as an output parameter and ensure the output was at least 48000 or
higher, and then all would work (I think!). Such features would, of
course, be at the user's risk. It would be easy for us to make mistakes
and mess things up, but we could also get things to work in unusual
circumstances, like mine.
It would also be handy to allow the sox program location to be
configurable (eg /usr/local/bin), so that C-3PO could use the revised
one without fear of being overwritten. I tried editing the C-3PO prefs
to do this, but the change got overwritten on each LMS restart.
LMS 7.9.1 on VortexBox Midi box, Xubuntu 17.10, FLACs 16->24 bit,
44.1->192kbps. Touch & EDO. 2nd Touch standard.
LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (to A308CR amp & ESLs) &
Marantz CR603 UPnP renderers.
Alternatively Minimserver & Upplay to same & to upmpdcli/mpd PC
renderers.
Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones.
Wireless Xubuntu 17.10 laptop firefox/upplay or Android 'phone with
Squeeze-Commander/BubbleUPnP controls LMS/Minimserver.
------------------------------------------------------------------------
PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642
View this thread: http://forums.slimdevices.com/showthread.php?t=105309
_______________________________________________
Squeezecenter mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/squeezecenter
