th2j wrote:
> I used squeezelite for a long time with LMS, and i am looking to the
> best audio quality
Would the "Audiophile" subforum be more appropriate?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a
th2j wrote:
> Recently i compared Squeezelite with aplay and i found that aplay sound
> more natural and relaxed.
How did you compare? "Natural and relaxed" refers to human mind and
perception, not anything objectively verifiable or related to
electronics or acoustics.
> I would like to know
philippe_44 wrote:
> What improvements do you precisely expect from that? I have a hard time
> to draw any causality with sq
Exactly my question as well. I hope it is not some audiophile
folklore
"To try to judge the real from the false will always be hard. In this
fast-growing art of
zaurux wrote:
> It seems that without using a realtime kernel, the preempt function
> improves things.
> In theory, from version 5.16, this feature improves and becomes "full"
> (with a lower latency without using a realtime kernel).
> I am not a specialist and able to produce exotic kernels
Grumpy Bob wrote:
> That said, I am using the earlier model of those headphones (the PX)
> with onboard BT from LMS and player running on a Pi Zero2 (and most of
> my flies are flac) and I'm quite happy with the sound quality. I think
> the biggest impact on sound quality it the level of noise
feeder6 wrote:
> Hi guys.
> I hope to get some info here.
> I want to connect a B P7 Wireless headphone via onboard bluetooth on
> my rpi4.
> This headphone supports aptx.
> Can you tell me if the sound will be lossy or lossless?
> All my music is stored as flac files.
> Hifiberry Dac2 is
Meanwhile, a tiny nit to pick - it is "Network Time Protocol", not
"Network Timing Protocol", as per RFC 958, RFC 1059, RFC119. RFC 1305
and RFC 5905...
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid
Man in a van wrote:
> Hi Julf, long time.
Hi, Ronnie - it has indeed been a while. :)
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
You need to install a bunch of dependencies. Can't find the list right
now - perhaps someone has it handy?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
DomCa wrote:
> Is it possible, to use two instances of the PiCoreplayer on RPI Zero Ws
> as a left and right speaker?
> I want to build two independent speakers each with its power supply and
> a RPI Zero W.
>
It is possible, but I doubt the synchronization between the channels is
good enough.
mcduman wrote:
> i have seen that the following settings are very popular in some
> configurations based on the argument that:
>
> 1. arm_freq, gpu_freq and sdram_freq should be multiples of each other
> 2. the lower the voltage, the better things are
> 3. sdram latency can be tweaked for
Great! Will be very useful for me, as I need the door bell (IP-enabled,
of course) to interrupt my music.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
steff wrote:
> This is my case: I have this PiCorePlayer in a box with amplifier,
> speakers and batteries.
> Wish to play my music even if I am, for example, at the sea, on the
> beach.
So why don't you just use a local player program instead of a network
player one?
"To try to judge the
Tony T wrote:
> I've noticed that the green light on my Raspberry Pi (Model B) will
> blink at random times (even when I'm not listening to music)
Renewing DHCP lease, synchronizing time, and a bunch of other regular
network activities.
"To try to judge the real from the false will always be
https://www.tecmint.com/rsync-local-remote-file-synchronization-commands/
'http://www.thegeekstuff.com/2010/09/rsync-command-example'
(http://www.thegeekstuff.com/2010/09/rsync-command-examples)
What you probably want is to run rsync on the RPi against a rsync server
on your mac, but the other
Dimdim wrote:
> That may be the case in general, but in this case these boards do
> decrease jitter (that has been documented by measurements)
Jitter at the DAC input or output?
> They say that delta-sigma DACs do a lot of complex math on the signal
> and that essentially "amplifies" even the
Dimdim wrote:
> If that were the case, Ian's FIFO reclocker or Kali or Acko's reclocker
> would have no reason to exist. You'd just put in a better clock.
Products exist because people buy them. There might or might not be a
real reason for it.
> I'm afraid that the jitter on every signal line
Linux normally comes with rsync that does just what you need - not sure
picoreplayer hasn't removed it.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
Dimdim wrote:
> From the de-jittered I2S signal coming from Kali. It's not just about
> MCLK - the rest of the I2S signals must be jitter-free, especially the
> BCLK.
Why? What does it affect? The audio output only depends on the audio
master clock of the DAC.
"To try to judge the real from
Dimdim wrote:
> The DAC will be running in asynchronous mode (utilizing its onboard
> oscillator) but there should still be significant improvement.
So if the DAC is running async from an internal clock, where would the
improvement come from?
"To try to judge the real from the false will
abartels wrote:
> Yes, EMI, is HF, yes. Why would you want to filter except for hf thrue
> mains? Just filtering for EMI?? Maybe build a Faraday cage???
So how does that go with your statement that "they don't have to filter
anything because there isn't any HF present"?
> I feel like
abartels wrote:
> Right, and they don't have to filter anything because there isn't any HF
> present, except for EMI/RFI. Get the picture?
But isn't EMI/RFI HF?
> The ultracaps are used as batteries, so to speak.
Not just "so to speak", they are pretty much the equivalent of
batteries, in
abartels wrote:
> Nope, it is transformerless design with 2 ultracap banks (one charging,
> one discharging) per voltage rail. In this case, 16 ultracap psu's (thus
> in total 32 Ultracap banks).
>
> NO reg's after ultracapacitors, no noise, no mains, deadquiet black
> backgrounds.
>
> 120
abartels wrote:
> For anyone interested, I build those psu's myself, based on 120
> Ultracapacitors in total, each 100F 2.7V
>
Preparing for a serious power outage?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will
andreame wrote:
> Great! Thank you so much! Everything works perfectly!!!
Except the second RPI probably can't access the internet (for updates
etc).
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
Greg Erskine wrote:
> I am not sure what happens if a device finds 2 DHCP servers, it probably
> uses the first one it finds?
Yes, that is what they do.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid
s2kiwi wrote:
> I feel nervous about using the SB via digital in there as all the FLAC
> material will need to be transcoded on the fly on the 'good' system
> which feels backward.
I don't really understand the problem. Why would the FLAC material need
to be transcoded?
"To try to judge the
drmatt wrote:
> I was looking forward to having a separate 5ghz WiFi at home, then I
> noticed it doesn't go through walls as well as 2.4ghz... and now I find
> i actually don't use it much..
I agree, it doesn't go through walls as well, but when you have 35
neighboring networks, you still
drmatt wrote:
> Well that's on the assumption that all the Pi are wired.
Or on a 5 GHz wireless network.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
Uffe.S wrote:
> According to my paper which I received from Telia, SSID should be
> written 08-76-FF-9C-29-9D
But the scan shows that the SSID is in fact
TeliaGateway08-76-FF-9C-29-9D.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity'
Roland0 wrote:
> Can't see an advantage in doing so - resource utilization, performance
> and quality would be identical, bandwidth consumption significantly
> higher.
I think it is one of those discussions that belong in the "audiophile"
section...
"To try to judge the real from the false
gtj wrote:
> I'm quite surprised ape format is not supported as it's popular and ever
> growing in the audiophile community.
Hmm... Why? What are the benefits?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a
Bas Horneman wrote:
> Seems I lied earlier. I get the same type of noise regardless of what
> setup I use. Amp (gainclone) and speakers are the same.
> Both on HifiBerry Pro and Duriosound...Even if I use a wifi dongle. Both
> use a high quality linear power supply. The duriousound even
Bas Horneman wrote:
> It's most audible during the start. But I think the noise is there
> continuously. It is UTP (2m) from a powerline connection.
Ah! Could the noise perhaps be caused by the powerline RF signal? It
would be a pretty wide bandwidth, variable noise signal - and with a
clear
Bas Horneman wrote:
> Ok...so different issue here. Mine was more noise as the music starts
> playing.
So you only get it when you start playing, not continuously? Is your
ethernet UTP of STP?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high
poing wrote:
> The shielding of ethernet cables can be a noise source. I'm not making
> any claims about about audibility, but a (German-language) computer site
> I trust considered that noise to be non-trivial in one of their setups.
The simple solution is to use normal unshielded (UTP)
DJDR wrote:
> What do you recommend to get the best soundquality, wifi or
> ethernetcable?
Ethernet has better reliability and throughput, especially on a Pi, so
it will give less of a risk of dropouts. If by "soundquality" you mean
something else, I suggest discussing it in the "audiophile"
thrasheur wrote:
> But for 32 bit files there is an error when reading the file and I think
> this is a driver problem as I use a generic one for ES9023, which is
> different as ES9018.
Considering I haven't yet come across a commercial recording that goes
beyond a 16 bit dynamic range, is 32
soundcheck wrote:
> That's weird. And Not nice.
Why? I think it is pretty much a "do what makes sense" rule.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
shadowlight wrote:
> Hello,
>
> New user of piCore and forum. I am currently using Piano with Kali. I
> have selected RaspiDac for now but is there a better setting for Piano
> that I should use? Also, any guidance on how to up sample? I searched
> for examples but was not successful.
>
>
Greg Erskine wrote:
> My understanding in Australia, you can't play music in public without
> paying royalties to the performer. A retail store would be considered a
> public place.
It's pretty much the same all over the world, but usually you don't need
to keep track of what you play - you
Greg Erskine wrote:
> As well as the extra networking, you also will need a database
> application that tracks what songs are played so you can pay the
> royalties to the appropriate performers.
A streaming service might need that. An end user doesn't.
"To try to judge the real from the
drmatt wrote:
> Reality includes crap like Trump and Brexit. I'm quite happy with my own
> brand of insanity instead.. :)
You have a point... :)
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge
drmatt wrote:
> Reality is most people don't care that much.
Most people don't care about reality that much.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W
drmatt wrote:
> Personally I am ambivalent about this. I don't much care if people want
> to buy esoterica that offers whatever improved X or Y or in fact nothing
> at all but a sense of style, or who want to tweak all day long. No one
> got hurt, no one went broke, and worst case scenario if
edwardthern wrote:
> Yeah you're right, I wouldn't call the folks here Audiophile's.
Thank you - I think most of us take that as a compliment.
> Better to let people know who can actually hear a difference.
Indeed. I recommend 'Computer Audiophile'
(http://www.computeraudiophile.com/forum/),
drmatt wrote:
> I would be very surprised if the chrt tweaks documented at the beginning
> of this thread had any effect to playback at all. Bits is bits, and
> short of having an actual buffer underrun on playback almost nothing
> else is likely to be audible.
I wish there was a way to add a
Pascal Hibon wrote:
> Careful not to forget the audiophile grade power cables to power the
> switches, modems, etc !
And I guess it all has to run off batteries. I still haven't found
sub-power stations with linear regulators.
"To try to judge the real from the false will always be hard. In
If you want to continue this discussion, I suggest you do it in the
"audiophile" subforum that exists precisely to protect other parts of
the forum from stuff like this.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will
edwardthern wrote:
> I agree, so are people who try to "Listen" by using some form of
> reasoning or looking at measurements.
Nobody is trying to listen by using reasoning or measurements, but many
of us are trying to actually understand and verify what is going on
instead of just assuming
edwardthern wrote:
> You listen and make your own list. Better yet run over to Rune audio and
> tell them to make a list for you...
Indeed. That is precisely how computers, amplifiers and other systems
are designed - by trying random things and seeing if the result happens
to work. All that
edwardthern wrote:
> Are you a scientist?
What is your definition of scientist? I have an academic background
electrical engineering and computer science, but I consider myself an
engineer, not a scientist - but even engineers have to understand and
apply the scientific method.
> Blue light?
edwardthern wrote:
> You guys are off the chart
>
> You guys are going through all this to try to show how smart you think
> your are buy really you are looking just the opposite.
>
I am sure that will help your argument to no end...
> Take your logic or lack thereof and apply it to other
edwardthern wrote:
> Let meet guess you're a aerospace engineer?
Should have gone for that, would have been more exciting than electrical
engineering.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edwardthern wrote:
> With so much negativity towards these simple little tweaks
If you see rational questioning of your claims as "negativity" I would
suggest you don't have much experience with academic peer review...
"To try to judge the real from the false will always be hard. In this
edwardthern wrote:
> Don't want to go off on a tangent.
Well, you might not have wanted to, but I think you succeeded. :)
> Double blind tests etc are used to prove something I'm not
> interested in a Nobel prize or proving anything to anyone. If someone
> tries a 'tweak' and feels they
edwardthern wrote:
> Lets just keep an open mind and listen to our ears.
Indeed. Let's listen to our ears, and only our ears. Not our eyes, nor
our preconceived notions or expectation biases.
Unfortunately the only way to do that is a controlled double-blind test,
something audiophiles hate.
feeder6 wrote:
> Now i have the same problem with an other album.
Does it play OK through the analog output of the RPi?
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many
feeder6 wrote:
> Sometimes i think i can hear some very short dropouts and some
> distortion. I am living in germany.
A different DAC (or connection to DAC) won't help with that - dropouts
are caused by network (and sometimes CPU load) issues.
"To try to judge the real from the false will
mudlark wrote:
> I strongly support that plan that "things to try" should remain just
> that rather than being integrated into the standard player.
And perhaps with a very clear "if you fiddle with these, and things stop
working, it's not our problem" form one has to acknowledge?
> Multi-core
edwardthern wrote:
> Don't want to cause trouble here and arguments about a/b tests etc.
>
> If people are in this much doubt it might be easier for me to just leave
> well enough along and enjoy my tweaks/mods etc by myself.
>
> please disregard my previous post and carry on
>
> Thank
edwardthern wrote:
> I don't want to say, what 'I hear' or the expected resultsonly
> because I don't want to bias peoples thinking or perception before they
> listen.
I guess there is still the implication/expectation that a) it makes a
difference, and b) that it is an improvement. I
Man in a van wrote:
> Where are the Home Service and Light Programme when we need them? and
> big old valve radios :cool:
Well, several of us have built in raspberry pis running squeezelite into
big old valve radios. Not quite the same, but...
"To try to judge the real from the false will
ctbarker32 wrote:
> I have recently contributed to an interesting Kickstarter project that
> might be of interest to Picoreplayer users
Fun and quirky, but isn't a 24/192 DAC rather overkill if the signal is
then "processed" by a 12AU7 tube stage (that clearly is there just to
"warm up" the
zordaz wrote:
> I know Morituri, but the last time I checked it it was a CLI tool and
> that is not what I prefer for ripping.
Ah, OK. Yes, it is CLI, and that is why I like it :)
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the
zordaz wrote:
> In the past I used Rubyripper and good old grip/cdparanoia sometimes,
> but I really missed the secure rip functions of EAC in those programs.
You mean checking against accurip database (as rubyripper does multiple
reads and verifies they are the same)? Have you tried morituri?
b0bb wrote:
> It is not about the "same bits".
>
> DoP goes up to DSD128, there is more material coming out in DSD256 now
> compared to a year ago, the XMOS and Amanero receivers will playback
> DSD256 in "native" mode over USB, this mode is what the lintweaker
> project enables.
Thanks! So
b0bb wrote:
> Are there any plans for native (non-DoP) DSD ?
What is the benefit? Both "native" (a bit of a misnomer) and DoP
transfer exactly the same bits - it is only a repackaging, not a
conversion.
"To try to judge the real from the false will always be hard. In this
fast-growing art of
Jeff07971 wrote:
>
> Got it working.
>
Great!
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W Klipsch, 1953
Jeff07971 wrote:
> Has anyone got a howto on how to put jivelite on a intel debian linux
> system?
If I remember correctly, I just cloned the git repo, and went "make".
There were a couple of libraries I had to install, but they were pretty
self-evident.
"To try to judge the real from the
For ripping I use 'morituri'
(http://thomas.apestaart.org/morituri/trac/), for tagging and management
I use 'beets' (http://beets.io/).
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will
Bas Horneman wrote:
> I tried that yesterday. No luck. That Ziggo is the same router it is
> used for the public hotspots.
Ah, OK, so it is just an alternate SSID.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear
Bas Horneman wrote:
>
> Scanning.
> -
> SSID Quality Level Channel
> Encryption Address
>
marcoc1712 wrote:
> But is a blog, it's easier...
True.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W Klipsch, 1953
JackOfAll wrote:
> Evidence and facts? So you're not the sort of person that would buy a
> DAC because it goes, Where no DAC has gone before! LOL.
No, I would not buy one just because of that. I'd be happy to test one
to see if it actually does - and I would also be happy to buy one based
on
marcoc1712 wrote:
> I dislike CA, but i dislike HA too, as in gneral dislike who always
> pretend to stay by the side of the 'real thruth'.
I like to determine truth based on evidence and facts, not whether it
happens to conform to my belief system or not. What do you think of the
marcoc1712 wrote:
> Shall I ask where, other than CA you could read about that matter?
I assume you are talking about Computer Audiophile, a commercial,
ad-sponsored site (where the advertisers are audiophool vendors). No the
best place for neutral advice - funny enough, the site tends to
mfsoa wrote:
> I tested shell to shell continuity of all the cables and the problem
> cable (an expensive "audiophile" brand that is the bees knees in many
> people's systems) was the only one that did not have continuity.
>
Glad you found the problem! Indeed, some "high-end" (snake oil)
soundcheck wrote:
> It seems I stepped on someone's toes. ;)
Just because people tell you you are wrong doesn't necessarily mean you
are right.
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge
bambadoo wrote:
> The rpi2 is connected to a xmos discrete based r-2r ladder dac
Wow, that brings back memories - my first DAC was a r-2r ladder on a
parallel output port, back in 1978. Fortunately technology has moved on
since then. :)
"To try to judge the real from the false will always be
Looks great! Nicely done!
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W Klipsch, 1953
Very nice!
"To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that will fool many people" - Paul W Klipsch, 1953
Julf's
hybride wrote:
> Imo this is always better then software. With software volume bits get's
> lost.
When someone says "always", they are usually wrong.
Software volume control "loses bits" only when you get down below the
dynamic range of your source material. Many software volume controls use
Murphyprecht wrote:
> Yes and I'm afraid I was just being facetious my friend ;)
I've actually come across people who seriously think of mining bitcoins
on RPI-class machines - until they do the maths. :)
"To try to judge the real from the false will always be hard. In this
fast-growing art
DJanGo wrote:
> that effect is not called audio quality thats called unusable :p
Unless you are into modern pop music, where the stuttering might be seen
as an useful effect. :)
> and a xserver or some python even on the earliest A RPI just for
> squeezelite and the 7inch display is far far
anadigi wrote:
> BTW, if there are too many stuffs running in the background, it will
> affect the sound quality too!
Yes, at the point when you have so many "stuffs" running that you run
out of memory or processing power. But that requites some pretty
heavy-duty "stuffs".
"To try to judge
Murphyprecht wrote:
> You CAN use your RPI to mine for bitcoins
Yes, but it would be very, very slow (unless you use the GPU). I was
just trying to think of something that causes a really heavy load.
"To try to judge the real from the false will always be hard. In this
fast-growing art of
Just installed jivelite on my latest music playing machine
(x86-64-based). It has a large touch screen, and I would like to use it
just with the touch screen, without mouse or keyboard. Unfortunately it
looks like the only way to go back a screen in jivelite requires the ESC
key - or am I missing
Furry wrote:
> Yes, I thought so, but wanted to check, just in case - because I would
> really go for it if it were offering general HD streaming. I'm pretty
> sure I can tell the difference, at least for much of the HD stuff I own
> (though I'm less convinced about 192k vs. 96k).
The
CommanderROR wrote:
> I honestly think 24/48 should be the new standard, because it offers the
> best quality/redundancy (24bit depth) without the risk of introducing
> ultrasonic frequencies that are harmful to the audible quality of the
> music.
24 bits makes sense when recording (to get
CommanderROR wrote:
> It is actually rather strange that you can't hear a difference, because
> when I tested it (original Pi B, not the B+) the analogue out had so
> much noise and distortion on it, that it was clearly audible, even on
> cheap PC speakers.
And there was no ground loop / gain
furnace wrote:
> Interestingly, I have just finished a fairly intensive listening test. I
> currently have a PiA and a PiB both with Hifiberry DACs installed and
> both running 1.21c. I hooked them up to the RCA inputs on my regular
> amp, one (PiA) using RCA/RCA from the Hifiberry, and one
Man in a van wrote:
> Well I'm sure your concern is reflected by all in this community, but I
> feel these "reach out" attempts are a little futile.
>
> Let the bloke be; wish him well, and if he wants to return, he knows
> we'll all be pleased to see him again.
Indeed, I think we should
philippe_44 wrote:
I wrote in another thread that I'd like to build a 3D printable case for
something like this but got little feedback, so I'm not sure there is
enough people interested to have a screen next to their pi running
squeezelite - I was a bit surprised
I guess part of the issue
TommySharp wrote:
Thanks i grabbed one off ebay for pretty cheap hopefully its not
too bad off the analogue off the raspberry pi... If its bad i guess i'll
need to get a DAC of some sort.
Really depends on your requirements. If you are using the speaker of the
old valve radio, I am
TommySharp wrote:
I do plan to replace the speakers in my valve radio and also try get all
the old knobs wired up to the raspberry pi to control volume, treble and
bass...
Haven't come up with a plan yet for the tuning knob.
Haven't done anything about tuning knob and tone controls - I
TommySharp wrote:
My goal is to take a raspberry pi with wifi and stuff it inside an old
hifi speaker I have. So I'm now hunting for a small amp that connects to
the Raspberry Pi that can drive the speaker.
There are lots of small, but good quality class D chip amp
boards/modules out there.
ralphy wrote:
Using the squeezebox clients link in my signature navigate to
jivelite-osx. See the readme for installation details.
Thanks!
To try to judge the real from the false will always be hard. In this
fast-growing art of 'high fidelity' the quackery will bear a solid gilt
edge that
I love jivelite on my linux machines - to the extent that my wife would
love to have it on her Mac too. I really don't want to set up a
compilation/development environment on her machine - would anyone have
binaries available?
To try to judge the real from the false will always be hard. In
probedb wrote:
It varies but to be honest any differences are going to be below the
threshold of human hearing so not worth worrying about :)
And even if it was audible, the answer would be depends on the DAC, so
there is no universal answer.
To try to judge the real from the false will
1 - 100 of 165 matches
Mail list logo
