pfarrell Wrote:
> Gentlemen, please. This is the audiophiles list.
GPWM, time to call a halt to my ranting.
--
CardinalFang
CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962
View this thread: ht
My SqueezeBox is replacing a network-based music system of my own
design. Until the SqueezeBox, I was listening to CDs playing from two
Sony Jukeboxes controlled by a Slink-e, a serial device from a
now-defunct company called Nirvis.
The software that controls the Slink-e consisted of a proxy ser
On Fri, 2005-12-23 at 09:31 -0500, Jacob Potter wrote:
> On 12/23/05, CardinalFang
> <[EMAIL PROTECTED]> wrote:
> > Perl does not encourage well written easy-to-maintain code.
> The same applies to C, and it's pretty hard to argue that the use of C
> leads to unsuccessful products.
Gentlemen, pl
On 12/23/05, CardinalFang
<[EMAIL PROTECTED]> wrote:
> Perl does not encourage well written easy-to-maintain code. The fact
> that there's an annual contest to write the most delibrately obfuscated
> code tells me a lot.
The same applies to C, and it's pretty hard to argue that the use of C
leads
Robin Bowes Wrote:
> CardinalFang said the following on 23/12/2005 09:25:
> >>>Java does allow you to wrap features up into nice,
> >>>self contained functional blocks that can be black box tested and
> >>
> >>then
> >>
> >>>left well alone. That's my main gripe with Perl, it isn't a
> language
>
CardinalFang said the following on 23/12/2005 09:25:
>>>Java does allow you to wrap features up into nice,
>>>self contained functional blocks that can be black box tested and
>>
>>then
>>
>>>left well alone. That's my main gripe with Perl, it isn't a language
>>>that enables that kind of unit cons
>
>
> > Java does allow you to wrap features up into nice,
> > self contained functional blocks that can be black box tested and
> then
> > left well alone. That's my main gripe with Perl, it isn't a language
> > that enables that kind of unit construction of an app.
>
> Agian, not so.
>
Sorry
CardinalFang said the following on 22/12/2005 12:00:
> Perl doesn't really allow you to encapsulate the core stable parts from
> further tinkering.
That is incorrect. Read up on Perl modules.
> Java does allow you to wrap features up into nice,
> self contained functional blocks that can be black
mwphoto Wrote:
> CardinalFang wrote:
>
> > Being able to easily change things isn't necessarily a good thing in
> a
> > mature product.
> >
>
> That's where we disagree! :) While the product may be considered mature
> in some sense (it is feature rich, stable, and relatively few bugs) I
> belie
CardinalFang wrote:
> Being able to easily change things isn't necessarily a good thing in a
> mature product.
>
That's where we disagree! :) While the product may be considered mature in
some sense (it is feature rich, stable, and relatively few bugs) I believe
it is a long way from the music se
mwphoto Wrote:
> One other significant advantage from the current perl implementation is
> that it is relatively easy to make changes and there is an established
> community building new features.
Being able to easily change things isn't necessarily a good thing in a
mature product.
Don't get
cbemoore Wrote:
> Do you realise that 2 of the biggest things being developed for the
> Slimserver 6.5 release are faster scanning and multithreading??
Yes I did, but all that means is that the original design didn't
anticipate large database performance and that it is being fixed now.
If a more
One other significant advantage from the current perl implementation is that
it is relatively easy to make changes and there is an established community
building new features.
While this is also possible with open source in any language I believe it
would take a long time to rebuild the community.
CardinalFang Wrote:
> Because SlimServer is flawed as it stands in not being multi-threaded
> and being very, very slow at times. Java has some good features for
> supporting threads and runs very fast on modern VMs. The SlimServer
> library scan times alone are enough to make me switch to anothe
Jacob Potter Wrote:
> I don't see how "Java front-end app plus from-scratch rewrite of
> SlimServer" is supposed to be better than "Java front-end app plus
> proven, tested, feature-complete SlimServer".
Because SlimServer is flawed as it stands in not being multi-threaded
and being very, very s
ezkcdude wrote:
Have any of you seen the Java clone of iTunes?
http://sourceforge.net/projects/jtunes4/. It's being hosted on
sourceforge.
looks like the project hasn't seen much action since the middle of 2004.
___
audiophiles mailing list
audiophile
Have any of you seen the Java clone of iTunes?
http://sourceforge.net/projects/jtunes4/. It's being hosted on
sourceforge.
--
ezkcdude
ezkcdude's Profile: http://forums.slimdevices.com/member.php?userid=2545
View this thre
On 12/20/05, CardinalFang
<[EMAIL PROTECTED]> wrote:
> It was fine in the early days when all that was needed was a enhanced
> scripting solution to push files around, but to remain commercially
> competitive, SlimServer needs to look as good as and be as
> ergonomically efficient as an Apple produ
Jacob Potter Wrote:
> As far as I know, a PC-based UI isn't even in the scope of that
> project. There's no reason why someone couldn't write a richer
> front-end for the current server (in whatever language) without
> throwing away everything that SlimServer already does.
> - Jacob
Perhaps not i
Jacob Potter Wrote:
>
> As far as I know, a PC-based UI isn't even in the scope of that
> project. There's no reason why someone couldn't write a richer
> front-end for the current server (in whatever language) without
> throwing away everything that SlimServer already does.
> - Jacob
What proj
On 12/18/05, CardinalFang
<[EMAIL PROTECTED]> wrote:
> I am encouraged by the Java server project that someone has started -
> on a PC with a modern VM it should run nearly as fast as native code
> and look good too. If that comes to fruition soon, then I think we have
> a fighting chance.
As far
Mike Anderson Wrote:
> On the other hand, if Slim Devices comes up with a really nice GUI for
> the Squeezebox, I'm married to it for good.
That's the really key thing, SlimServer looks OK, but it is so
painfully slow to use and the web interface makes it really hard to
give good feedback to the
dwc Wrote:
> I'd never go Apple. I prefer freedom.
> -Dan
Many people will though for the ease of use and strong integration -
iPod has trounced all comers in its market. I like the audiophile and
hackability side of SB and I don't think Apple will go that way myself,
but I do think they may swe
I'd never go Apple. I prefer freedom.
-Dan
--
dwc
dwc's Profile: http://forums.slimdevices.com/member.php?userid=1892
View this thread: http://forums.slimdevices.com/showthread.php?t=18991
___
Unless Apple makes something that can deal with FLAC (and so far they
haven't), I won't be buying it. If it does FLAC, sounds as good as the
Squeezebox, and uses the iTunes frontend, I'll have to think about it
very hard.
On the other hand, if Slim Devices comes up with a really nice GUI for
the
cliveb Wrote:
> Now you've really spoiled my day. The prospect of the Apple steamroller
> squashing the likes of Slim Devices (like they did to Rio) is just too
> depressing to contemplate.
I actually edited this bit out of my response as I thought it might be
the wrong place to put it, but yes,
Patrick Dixon Wrote:
> Surely in base 4, 2+2 = 10?
err yes. Oops. Serves me right for typing answers late at night and not
re-reading them.
My point was really that what we are discussing is defined behaviours,
not "facts".
--
CardinalFang
-
> Actually, 2+2=0 in base 4 (for all you 4-bit ALU computing fans
> from the 1970's). 2+2=4 only under very specific conditions.Surely in base 4,
> 2+2 = 10?
--
Patrick Dixon
www.at-tunes.co.uk
Patrick Dixon's Profile: h
CardinalFang Wrote:
> I don't think I clained it did suddenly acquire extra data from thin
> air.
OK, sorry, I obviously misinterpreted this statement you made:
> Where I get my reasoning from is derived when you browse CDs in windows
> explorer where the audio is presented as data tracks and the
cliveb Wrote:
> Disagreement over opinions is one thing, disagreement over facts is
> another. If I were to disagree that 2+2=4, I'd be wrong.
Actually, 2+2=0 in base 4, for all you 4-bit ALU computing fans
from the 1970's
Come at things from a different angle and "facts" can be subtly
changed.
cliveb Wrote:
>
> As it happens, I'd never tried copying a track from an audio CD using
> Explorer, so I've just done it: dragged "Track01.cda" from the CD drive
> to the hard disk. What I ended up with was a 44 byte file containing a
> RIFF header and no audio data at all. This was using Window
CardinalFang Wrote:
> Well you also need to accept that I because I don't agree doesn't make
> me wrong. I grasp all your points, I just don't agree with all of them.
Disagreement over opinions is one thing, disagreement over facts is
another. If I were to disagree that 2+2=4, I'd be wrong.
> Wh
teanau Wrote:
> thats a great call mr fang.
> especially if it could be done quietly in the background over night.
>
> i imagine the same set up is fraught with the potentual to corrupt alot
> of perfectly good cds too if tampered with.
>
> a legal mine field too.
> but could alleviate alot of
thats a great call mr fang.
especially if it could be done quietly in the background over night.
i imagine the same set up is fraught with the potentual to corrupt alot
of perfectly good cds too if tampered with.
a legal mine field too.
but could alleviate alot of audio health hypocondria...
_s
cliveb Wrote:
> I will admit to becoming increasingly exasperated that you seem unable
> to grasp the points I've been trying to explain, and this is the reason
> for the gradual decrease in politeness. I'm not trying to make you look
> stupid - I'm trying to explain something, but do acknowledge
CardinalFang Wrote:
> please be less aggressive over what is meant to be a friendly
> discussion. I was trying to debate the pros and cons of different
> methods of audio playback and you're trying to make me look stupid - I
> assure you I have a brain between my ears.
I'm sorry if I seem aggress
'This article' (http://www.positive-feedback.com/Issue22/nugent.htm) by
Mr. Empirical Audio gives some answers to several questions regarding
this issue.
--
vdorta
DIY computer (EAC, AccurateRip, FLAC) --> wireless SB2 (Bolder digital &
analog mods, Sonicap Platinum bypass caps, Bolder Deluxe
cliveb Wrote:
> Do you actually understand the difference between error correction
> (which happens *continuously* while reading even a pristine CD) and
> error concealment (which happens very rarely - in fact usually not at
> all on an undamaged CD)?
I admit that CD audio is not my expert field
CardinalFang Wrote:
> Data drives also have more capabilities than audio only drives.
Not when they're reading audio CDs, they don't.
> Offline rather than real-time allows you to spend more time and
> processing power to make corrections or gather the correct data.
No. On a "copy-protected" CD
cliveb Wrote:
> Those CDs include deliberate uncorrectable errors, and rely on the CD
> player's interpolation algorithms to conceal them. So how do you plan
> on copying them to your hard disk?
Data drives also have more capabilities than audio only drives. Offline
rather than real-time allows
Thanks very much for the list of corrupt CDs. It made very interesting
reading. I found a couple of disks on there that EAC was struggling
with when extracting using my LG DVD Rom (Beatles, Let it be Naked and
Pink, Try this).
However I did find that my NEC DVD Writer combined with EAC managed t
CardinalFang Wrote:
> OK, can I point you at this web site that lists all the CDs with
> deliberately error-laden data to try to fool computer CD drives. It is
> not an incorrect assumption that CDs are not manufactured error-free
> anymore but a well-documented one with several sites reporting
>
cliveb Wrote:
> Your argument seems to be based on the assumption that CDs are rarely
> read correctly, and error concealment is required most of the time.
> This assumption is incorrect.
OK, can I point you at this web site that lists all the CDs with
deliberately error-laden data to try to foo
On Mon, 2005-12-12 at 02:43 -0800, cliveb wrote:
> CardinalFang Wrote:
> > I read in the article that since the sound data is extracted via
> > computer onto hard disk and because computers need bit-perfect data, we
> > are getting a more acccurate experience than a CD player that
> > error-correc
CardinalFang Wrote:
> I read in the article that since the sound data is extracted via
> computer onto hard disk and because computers need bit-perfect data, we
> are getting a more acccurate experience than a CD player that
> error-corrects and filters data on-the-fly.
Your argument seems to be
bludragon Wrote:
> I think that's pretty optimistic, unless living in the US means you have
> to suffer some really bad 'audiophile' equipment, or you're comparing it
> to something designed well over 5 years old.
>
> That whole part of the article seemed more like hearsay to me. Yes,
> squeeze
On Sat, 2005-12-10 at 16:28 -0800, bludragon wrote:
> pfarrell Wrote:
> > So you should expect it to sound as good as
> > a $1000 or more 'audiophile' CD player.
> I think that's pretty optimistic, unless living in the US means you
> have to suffer some really bad 'audiophile' equipment, or you'r
pfarrell Wrote:
> On Sat, 2005-12-10 at 13:02 -0800, CardinalFang wrote:[color=blue]
> So you should expect it to sound as good as
> a $1000 or more 'audiophile' CD player.
>
I think that's pretty optimistic, unless living in the US means you
have to suffer some really bad 'audiophile' equipmen
48 matches
Mail list logo
