PDA

View Full Version : Native AAC Support



samlw
2005-12-15, 18:13
Hi,

Are there plans to add native AAC support to the Squeezebox? Not the DRM version - just plain AAC. I bought my Squeezebox expecting to be able to have a central music library accessible by both iTunes and the Squeezebox via SlimServer. However, I want to store the music uncompressed. So this rules out MP3, which seems to be the only common denominator format between iTunes and SlimServer.

FLAC is not supported by iTunes. And AAC is not directly supported by SlimServer. (And no, I don't want to install extra software modules like LAME to convert my uncompressed music to "high quality MP3!")

Why doesn't the Squeezebox simply support AAC in firmware? Is there a licensing issue? The Roku SoundBridge products have such support as far as I can tell...

Thanks,

Sam

seanadams
2005-12-15, 18:36
You don't need to install anything for AAC support as it's decoded by quicktime. Native AAC support would really be of limited benefit (some bandwidth savings). The roku needs AAC in firmware because they don't have the ability to play it otherwise.

kolepard
2005-12-15, 18:42
>However, I want to store the music uncompressed... (And no, I don't
>want to install extra software modules like LAME to convert my
>uncompressed music to "high quality MP3!")

Then you don't want AAC anyway. And if you've encoded your music
with AAC, then you've compressed it. AAC is a compressed file,
similar to MP3, merely a different codec.

If you want to use a lossless format supported by iTunes, you'll
probably have to use Apple Lossless (is that what you meant? Not
AAC?), which I presume is supported by iTunes. But if you're willing
to accept compression with AAC, there isn't any reason to reject it
with MP3. Just find an encoding bit-rate that is acceptable to you.
Installing the iTunes-LAME program in iTunes is trivial.

>Why doesn't the Squeezebox simply support AAC in firmware?

"Simply"? Implementing a codec in firmware is probably not a trivial
task. And since AAC is a lossy codec just as MP3 is, there isn't a
lot of reason to do it, especially with MP3 being a more universally
supported encoding method.

As for Apple Lossless, it is not widely used. I'm a big Apple/Mac
fan and user, but I use FLAC, not Apple Lossless.

Basically, I conclude that there isn't enough demand and other tasks
are higher priority.

Kevin
--
Kevin O. Lepard

Happiness is being 100% Microsoft free.

radish
2005-12-15, 22:28
AAC is supported in slimserver, you don't need to transcode to mp3, you can transcode to wav or flac for streaming, both are lossless. I really don't see your problem.

samlw
2005-12-16, 00:35
Sorry, perhaps I made an invalid assumption. I assumed Apple Lossless was just a lossless variant of AAC. Don't they both have the same file extension?

At any rate, what I want is a compressed lossless format like FLAC or Apple Lossless that is natively supported by both iTunes and Squeezebox. My music server does not have the horsepower to convert the datastream to another format on the fly. And I don't want it converted to a lossy format like MP3.

If my music is stored as FLAC, then iTunes won't play it. And if it is stored as Apple Lossless, then Squeezebox won't play it.

Is there no solution to this that doesn't involve on-the-fly format conversion on the server?

samlw
2005-12-16, 00:42
You don't need to install anything for AAC support as it's decoded by quicktime. Native AAC support would really be of limited benefit (some bandwidth savings). The roku needs AAC in firmware because they don't have the ability to play it otherwise.
Sean, the music is not stored on a Mac. It is stored on a LinkStation that feeds streams to iTunes via mt-daapd and to Squeezebox via SlimServer. Native AAC support would be a benefit because then my music could be stored on the server (LinkStation) as AAC and then streamed to iTunes and Squeezebox natively with no decoding on the server (which has very limited horsepower). In my experience, AAC yields higher quality sound than MP3 at a given bit rate. So to me, that is a big benefit to having AAC support in the Squeezbox firmware. And the Roku therefore has an advantage over the Squeezebox in this regard.

bishopdonmiguel
2005-12-16, 05:23
> You don't need to install anything for AAC support as it's decoded by quicktime. Native AAC support would really be of limited benefit (some bandwidth savings).

I'm a longtime slim user and love these things, but I'm with samlw on this issue. It's not about bandwidth, most of us have gobs a-plenty, it's about server resources. The decoder processes can be very CPU intensive and undesirable on older equipment to the point of dropouts, etc., especially when you have multiple players. You are essentially forced into a lossy format unless you want to upgrade your server.

Personally, I don't think a format should really be considered "officially supported" until it exists in firmware. Although flexible, server-side decoders are really nothing more than workarounds. It would be nice if the major formats were directly supported. I know these things change over time, but the life-cycle of the Squeezebox hasn't exactly been long-term.

I run a mixed PC/Mac environment and choosing the "right" lossless format is not as simple as one might think. FLAC is a GREAT choice in theory, but the fact is the major players (iTunes, WMP) don't support it. The mainstream lossless choices are WMA and Apple. Slim can play FLAC but both WMP and iTunes cannot. WMP can play WMA Lossless but not Apple Lossless or FLAC. iTunes can play Apple Lossless but not WMA Lossless or FLAC. Proverbial catch-222.

radish
2005-12-16, 08:28
You are essentially forced into a lossy format unless you want to upgrade your server.
I don't understand this. In my experience, converting to a lossy format takes MORE horespower than to a lossless one.


is a GREAT choice in theory, but the fact is the major players (iTunes, WMP) don't support it
iTunes is the only major player I'm aware of that won't play flac. There are plugins for WMP, and Winamp/Foobar/etc all play it out of the box. Blame Apple for not supporting it and not allowing plugins to add support.

The problem here is proprietary formats, but what baffles me is how people blame Slim for supporting the open ones. Apple want to tie you into iTunes/AAC, Microsoft want to tie you into WMP/WMA, Slim just want you to be able to listen to your music. As soon as these companies start (a) licensing their formats so other people can play them or (b) supporting the open standards - then we'll all be happy. Until then, complain to them.

Josh Coalson
2005-12-16, 09:34
--- samlw <samlw.204h0n (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> Sorry, perhaps I made an invalid assumption. I assumed Apple Lossless
> was just a lossless variant of AAC. Don't they both have the same
> file extension?
the file extension is for the container format, not the codec format
inside. AAC and apple lossless are totally different codecs.

> At any rate, what I want is a compressed lossless format like FLAC or
> Apple Lossless that is natively supported by both iTunes and
> Squeezebox. My music server does not have the horsepower to convert
> the
> datastream to another format on the fly. And I don't want it
> converted
> to a lossy format like MP3.
>
> If my music is stored as FLAC, then iTunes won't play it. And if it
> is
> stored as Apple Lossless, then Squeezebox won't play it.
>
> Is there no solution to this that doesn't involve on-the-fly format
> conversion on the server?

no.

in addition to asking here, I'd say to also hedge your bets and
petition apple for FLAC support in itunes as many others have done.
maybe if the volume gets loud enough they'll do it.

Josh

mikerob
2005-12-16, 09:50
Although I understand that non-DRM AAC isn't proprietary - it is defined as part of the MPEG-4 standards.

That's not to say there isn't licensing issues with AAC (just as there is with MP3 - hence LAME) - but Roku and lots of other applications have implemented AAC. My Sony Ericsson mobile phone plays AAC tracks as ringtones without a problem.

I'm sure it is a priority call by Slimdevices - while AAC may not be a proprietary technology, I'm sure there are lots of other things that are higher priority than native AAC on the Squeezebox given there already is a workable solution based on server transcoding.

bishopdonmiguel
2005-12-16, 10:08
> I don't understand this. In my experience, converting to a lossy format takes MORE horespower than to a lossless one.

If your goal is to keep CPU activity to a minimum, you have to choose a path sans transcoding. Transcoding effectively eliminates many "supported" formats if it causes performance problems and you are left to choose from those available in the player. For a SB1, MP3 is the only real choice which led to my comment. Many of us cannot justify moving on to SB2/SB3 simply for FLAC and WAV just takes too much space. I think the long term goal should be to support all major formats (where possible) in firmware. That's just my opinion, it might not be popular and I have respect for any others but I'm honestly not sure if I will ever upgrade without wider native support. Let the user choose the best flavor for their situation without the worry about burdening the server.

> iTunes is the only major player I'm aware of that won't play flac. There are plugins for WMP, and Winamp/Foobar/etc all play it out of the box.

Well, I'm not much of an iTunes fan and my lossless format of choice right now is WMA. I wasn't aware that Microsoft had a FLAC plugin for WMP so I will have to look for that. I do realize there are other players available but I suppose I was referring to the majors as those available for free that have the highest install base. I assume iTunes for Mac and WMP for Windows are the major players, but I most definately could be wrong.

> The problem here is proprietary formats, but what baffles me is how people blame Slim for supporting the open ones.

You misunderstand my position. I applaud Slim for supporting FLAC and would like nothing more than to see MS/Apple do the same. I don't blame Slim for not supporting proprietary formats if doing so is impossible. I don't know enough about the process to know if it's a "choice not taken" or a "choice not available." As an "average user," I rarely look further than what is installed by default and for free. I don't think I'm unusual in that regard and the formats supported by the major applications are the ones that naturally have the highest usage. For the average user who wants lossless, the choice is WMA or M4P. This isn't a rip on Slim or FLAC it's just a fact of life.

Marc Sherman
2005-12-16, 10:11
--- samlw <samlw.204h0n (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>>
>> Is there no solution to this that doesn't involve on-the-fly format
>> conversion on the server?

Josh Coalson wrote:
>
> no.

Sure there is. If you've got lots of disk space but not much excess CPU
power, you can write a script that transcodes your FLAC collection to
one or more additional formats on disk, in a parallel tree. You'd put
that script in a cron job that runs over night to keep the secondary
formats in sync as you rip new flacs. Point your slimserver at the
FLACs, and point iTunes at the AACs.

If your server is tight on both CPU and disk, then you really should
consider upgrading it.

- Marc

radish
2005-12-16, 11:11
Although I understand that non-DRM AAC isn't proprietary - it is defined as part of the MPEG-4 standards.

But Apple Lossless (ALAC) is not AAC, or MPEG-4, and as far as I know is not available for licensing. So whilst Slim could (in theory) add native AAC support, I don't believe it's possible for them to add ALAC.



Let the user choose the best flavor for their situation without the worry about burdening the server.

I think you're at odds with the SlimDevices ethos - that the player should be, well, slim. Computing power at the server end is cheap, and the player end it's expensive. In my case my server isn't doing anything else most of the time, it may as well be transcoding. I'd rather that than pay $100 extra per player to do it at the other end. YMMV.

dean
2005-12-16, 11:30
On Dec 15, 2005, at 11:35 PM, samlw wrote:

>
> Sorry, perhaps I made an invalid assumption. I assumed Apple Lossless
> was just a lossless variant of AAC. Don't they both have the same file
> extension?
They are completely different codecs, but use the same wrapper, which
is based on the QuickTime file format.


> At any rate, what I want is a compressed lossless format like FLAC or
> Apple Lossless that is natively supported by both iTunes and
> Squeezebox. My music server does not have the horsepower to convert
> the
> datastream to another format on the fly. And I don't want it converted
> to a lossy format like MP3.

> If my music is stored as FLAC, then iTunes won't play it. And if it is
> stored as Apple Lossless, then Squeezebox won't play it.
It will, but at the cost of conversion from AAC to FLAC using
QuickTime. Have you found that this conversion is particularly CPU
intensive? My experience is that it is not. What's the speed of the
server computer?


> Is there no solution to this that doesn't involve on-the-fly format
> conversion on the server?
Not at this time.

samlw
2005-12-16, 17:05
On Dec 15, 2005, at 11:35 PM, samlw wrote:

> If my music is stored as FLAC, then iTunes won't play it. And if it is
> stored as Apple Lossless, then Squeezebox won't play it.

It will, but at the cost of conversion from AAC to FLAC using
QuickTime. Have you found that this conversion is particularly CPU intensive? My experience is that it is not. What's the speed of the server computer?

Hi Dean,

As I mentioned in my reply to Sean, my server is not a Mac, so QuickTime is not available to do the transcoding. The server is a low-powered LinkStation with limited CPU and RAM resources. While a fully lossless format (ALAC) that is natively supported by both iTunes and Squeezebox would be ideal, I would be happy with high bit-rate AAC if it were natively supported in firmware. The Roku SoundBridge does this, so it is clearly possible.

samlw
2005-12-16, 17:08
--- samlw <samlw.204h0n (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>>
>> Is there no solution to this that doesn't involve on-the-fly format
>> conversion on the server?

Josh Coalson wrote:
>
> no.

Sure there is. If you've got lots of disk space but not much excess CPU
power, you can write a script that transcodes your FLAC collection to
one or more additional formats on disk, in a parallel tree. You'd put
that script in a cron job that runs over night to keep the secondary
formats in sync as you rip new flacs. Point your slimserver at the
FLACs, and point iTunes at the AACs.

If your server is tight on both CPU and disk, then you really should
consider upgrading it.

- Marc
Thanks for the suggestion, but - how do I put this - Yuck! Seriously, maintaining a parallel tree with separate formats is just way too inelegant to even contemplate - IMHO, it goes against everything the Squeezebox stands for!

seanadams
2005-12-16, 17:41
samlw,

Your situation is not typical at all - nearly everyone using AAC is on Mac/Windows (or a linux machine capable of running faad), in which case it simply works. I'm not sure why you keep pushing the SoundBridge button - we are well aware that porting codecs is "possible", but I think you underestimate the cost of implementing and licensing codecs for an embedded system. As we've said, the benefits are relatively miniscule in the case of AAC, given that it already works just fine on any of our supported platforms. That's not to say it won't happen - just that it's not a high priority.

BTW if you ever need to use ANY lossless format (Flac, Apple, WMA) or any non-mainstream/emerging format, you will be very glad you chose Squeezebox. :)

We do appreciate the feedback though, and client-side AAC is understood as a desirable feature.

Sean

Jacob Potter
2005-12-16, 18:20
On 12/16/05, seanadams <seanadams.205sgz (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> BTW if you ever need to use ANY lossless format (Flac, Apple, WMA) or
> any non-mainstream/emerging format, you will be very glad you chose
> Squeezebox. :)

For more reasons than one, considering the AC'97 chip in the Tubular
Music Player...

- Jacob

mkozlows
2005-12-16, 19:56
While a fully lossless format (ALAC) that is natively supported by both iTunes and Squeezebox would be ideal, I would be happy with high bit-rate AAC if it were natively supported in firmware. The Roku SoundBridge does this, so it is clearly possible.

The SoundBridge doesn't support Apple Lossless -- nobody does, because it's part and parcel of Apple's hyper-proprietary world. And while the SoundBridge does support AAC, what's the benefit of AAC for you? If high-bitrate lossy is acceptable, just use MP3 and get universal compatibility.

Marc Sherman
2005-12-17, 09:21
samlw wrote:
> Thanks for the suggestion, but - how do I put this - Yuck! Seriously,
> maintaining a parallel tree with separate formats is just way too
> inelegant to even contemplate - IMHO, it goes against everything the
> Squeezebox stands for!

To be honest, that's the same reaction I have when I see people talk
about running slimserver on underpowered NAS boxes, and then start
pushing for more features to be added to the (proprietary) firmware
because their server can't handle running the (open-source) code that
implements those features server-side.

- Marc

samlw
2005-12-17, 12:57
samlw,

Your situation is not typical at all - nearly everyone using AAC is on Mac/Windows (or a linux machine capable of running faad), in which case it simply works. I'm not sure why you keep pushing the SoundBridge button - we are well aware that porting codecs is "possible", but I think you underestimate the cost of implementing and licensing codecs for an embedded system. As we've said, the benefits are relatively miniscule in the case of AAC, given that it already works just fine on any of our supported platforms. That's not to say it won't happen - just that it's not a high priority.

BTW if you ever need to use ANY lossless format (Flac, Apple, WMA) or any non-mainstream/emerging format, you will be very glad you chose Squeezebox. :)

We do appreciate the feedback though, and client-side AAC is understood as a desirable feature.

Sean
Sorry, I don't mean to "push the SoundBridge button." I think the Squeezebox is a great product, or I wouldn't have bought one. I only bring it up because AAC/iTunes integration is a differentiating feature of what I perceive to be Squeezebox's main competitor.

You say that my case is atypical. However, a simple google search will turn up many many users of LinkStation and other low-power NAS devices as music servers feeding Squeezboxes. Its a great thing to have a small quiet 17w server dedicated to streaming your music library, rather than operating a hulking power-hungry noisy desktop computer 24/7. The combination of LinkStation + Squeezebox is such an elegant one that I'm surprised Slim hasn't pursued an official partnership with Buffalo. But I digress.

In my case, I am running mt-daapd on my LinkStation. This serves shared music to all iTunes clients on my network. If Squeezebox incorporated a daap client, it would be able to see and play all that music, as well as any music being shared by any other instances of iTunes music sharing on the network. This of course would not preclude using SlimServer to gain access to additional formats and features, for those who want it. But I think this would be a great feature for the Squeezebox. For one thing, the unit could be up and running and playing music out of the box without requiring installation of any software (for iTunes music sharing folks, at any rate).

Anyway, just my 2 cents. Thanks for listening. And thanks for making a great product. I'm just offering some ideas that I think would make it even better. :)

samlw
2005-12-17, 12:58
The SoundBridge doesn't support Apple Lossless -- nobody does, because it's part and parcel of Apple's hyper-proprietary world. And while the SoundBridge does support AAC, what's the benefit of AAC for you? If high-bitrate lossy is acceptable, just use MP3 and get universal compatibility.
I think high-bitrate MP3 is the way I will have to go. In my experience, AAC sounds better and compresses better than MP3 at a given bitrate. So I have a personal preference for AAC over MP3.

samlw
2005-12-17, 13:08
samlw wrote:
> Thanks for the suggestion, but - how do I put this - Yuck! Seriously,
> maintaining a parallel tree with separate formats is just way too
> inelegant to even contemplate - IMHO, it goes against everything the
> Squeezebox stands for!

To be honest, that's the same reaction I have when I see people talk
about running slimserver on underpowered NAS boxes, and then start
pushing for more features to be added to the (proprietary) firmware
because their server can't handle running the (open-source) code that
implements those features server-side.

- Marc
Fair enough! For my part, I prefer to have a low-power (17w) small silent dedicated server that can be left running all the time so that my music is always available. Leaving a large noisy power-hungry desktop maching running 24/7 for this purpose strikes me as inelegant and wasteful of resources. But that's just my personal preference. And for the record, I don't want to see the Squeezebox firmware become bloated or the product become more expensive. But I do think that perhaps the optimal balance has not yet been achieved. There's always room for improvement, right?

Oh, and BTW - I'm a huge proponent of open source and I love that SlimServer exists. Its relatively open architecture is one of the reasons I chose Squeezbox. But this doesn't preclude making the product a bit more flexible and usable by carefully and selectively enhancing the firmware side as well...

el payo
2005-12-17, 13:25
I run SlimServer on a slightly tweaked, dedicated PowerMac G4 Cube running Tiger. Silent, small and fits right between components in my audio/video setup. The only drawback is that the Cube doesn't support internal drives over 120GB due to the IDE controller, but you can either pull a little software foo and install a larger internal drive or hook up an external drive to a FireWire port.

kolepard
2005-12-17, 13:39
>I run SlimServer on a slightly tweaked, dedicated PowerMac G4 Cube
>running Tiger.

I run it on a 700 MHz G3 iMac. That model was designed so it could
run entireless fanless. If you stick your ear right up to it, you
can occasionally hear the hard drive whir, but that's it.

Kevin
--
Kevin O. Lepard

Happiness is being 100% Microsoft free.

Christian Pernegger
2005-12-17, 14:17
> If your goal is to keep CPU activity to a minimum,

Why is that your goal? Slimserver's CPU requirements are
next-to-nothing when it's not rescanning. Disk performance is much
more of a problem, especially if it is not the only process requiring
disk access on the host.

> you have to choose a path sans transcoding.

If you hate transcoding so much, just reencode your library and keep a
FLACed copy around.

> only real choice which led to my comment. Many of us cannot justify
> moving on to SB2/SB3 simply for FLAC

Then move because of the vastly superior sound and display quality perhaps?

> I think the long term goal should be to support all major formats
> (where possible) in firmware.

I really don't. The whole point of the SB is to be a slim device, so
as much of its behaviour as possible can be changed in the open source
server software. Much less prone to bugs and locked-up units that way.
I DO think however that handling of transcoded streams should be
changed so that they allow seeking.

> For the average user who wants lossless, the choice is WMA or M4P.

Where'd you get that from ???

Anyway, I suggest upgrading your server, keeping a FLACed mirror tree
or, best of all, stop using iTunes.

C.

bishopdonmiguel
2005-12-17, 15:49
> Why is that your goal?

On a low-powered system, transcoding causes burps in the music and it completely ruins the listening experience so you try to limit whatever you can. I suppose I could upgrade the server, but I have already invested significantly in the players. More $$$ isn't really an option.


> If you hate transcoding so much, just reencode your library and keep a FLACed copy around.

An option, surely, but a single library is enough to maintain.


> Then move because of the vastly superior sound and display quality perhaps?

Only when the prices drop significantly.


> Where'd you get that from ???

Most "average users" likely use WMP or iTunes. The lossless choices are WMA or M4P. I think if you asked an "average user" what FLAC was, they'd have no idea and probably not care. If FLAC is ever supported by WMP/iTunes, it will become a major format, but I won't hold my breath.

stinkingpig
2005-12-17, 18:29
....
>
> Most "average users" likely use WMP or iTunes. The lossless choices
> are WMA or M4P. I think if you asked an "average user" what FLAC was,
> they'd have no idea and probably not care. If FLAC is ever supported
> by WMP/iTunes, it will become a major format, but I won't hold my
> breath.

Lemme get this straight -- you didn't buy the Squeezebox at Best Buy, did
you? Didn't read a review in some glossy Ziff Davis magazine, right?
Rather, you had to do some research to find out about it, and maybe some
more research to ensure that it was the best solution for your needs. Then
you had to buy it online and wait for it to be shipped, instead of taking
the "average user" instant gratification route.

Same goes for your NAS, right? So what's up with playing the "average
user" card now that it comes to selecting a format to stream in? Or is
this a "never mind my needs, What About The Children?" argument? Just
trying to keep it straight.

--
Jack At Monkeynoodle.Org: It's A Scientific Venture...
"Believe what you're told; there'd be chaos if everyone thought for
themselves." -- Top Dog hotdog stand, Berkeley, CA

Christian Pernegger
2005-12-17, 19:37
> On a low-powered system, transcoding causes burps in the music.

I cannot begin to imagine how low-powered this system would have to
be. A flakey wireless connection, maybe. A slow disk with some other
concurrent accesses, maybe. Not the transcoding. Both FLAC and AAC run
fine on battery-powered devices.

Incidentally the SB2 and up have a far larger buffer - you'd have to
torture the server to get dropouts.

Looks to me you want to solve a problem you have with an SB1 and an
underpowered server by adding a feature no-one else needs to the
firmware of an SB2, which however wouldn't exhibit the problem in the
first place.

> Most "average users" likely use WMP or iTunes.

Might be, since when is that a reason to do the same? Most likely your
"average user" doesn't know what a Squeezebox is, either. Hell,
average users tend to have their Windows machines chock-full with
spyware ...

One lossy and one lossless format in firmware is enough, provided the
server gains the ability to seek through these files and to transcode
radio streams.

C.

Ben
2005-12-17, 22:25
I don't see why this is being taken as such an absurd request by some. Sean has certainly made clear Slim's reasons, and he makes a lot of sense. But it it was almost a deal breaker for me when I first purchased my Squeezebox. I bought a SB1 and a Soundbridge M1000 to compare head to head. The SB1 always burped on AAC transcodes, while the M1000 played them perfectly over the same connection. With my server being my main day-to-day machine, I didn't want to mess with transcoding either. Luckily for me, the SB2 came out with 30 days of my SB1 purchase, so I returned both the SB1 and the M1000 and got a SB2. While the SB1 had a lot more power and possibility, the M1000 had a bit smoother out of the box experience.

I'm not sure what the harshness towards 'average users' is all about. While Slimserver and Squeezebox are wonderful and have a fantastic number of options, it does sometimes seem that ease of use and simplicity take a back seat. Again, only going by my experience, but I've had the SB2 for going on a year now, and my wife still can't get the hang of it. She's far from a techie, but she still prefers to take 5 CDs from their cases, put them in the player and hit shuffle... This is as opposed to our Tivo, which, in a sense, is a similar type of device. She took to that very easily, and now couldn't live without it. There is something to be said for ease of use.

Sorry about the threadjack there, but it was just a bit discouraging to see a couple of posts with folks disparaging 'average users' who may not live and breath this stuff and want to spend every waking moment fiddling with it...

Ben Sandee
2005-12-18, 00:03
On 12/17/05, Ben <Ben.2080kb (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Sorry about the threadjack there, but it was just a bit discouraging to
> see a couple of posts with folks disparaging 'average users' who may not
> live and breath this stuff and want to spend every waking moment
> fiddling with it...


So what you're trying to say is that your average user wife wants AAC
support in the firmware? I seriously doubt that's that case and I think
that's the real point. The average user doesn't know the difference between
MP3 and FLAC and AAC and ALAC. Adding AAC to the firmware would not benefit
the average user in any way that the average user would be able to
comprehend. Nothing wrong with that, not disparaging average users, it's
just the way things are.

Ben

stinkingpig
2005-12-18, 08:36
....
> I'm not sure what the harshness towards 'average users' is all about.
> While Slimserver and Squeezebox are wonderful and have a fantastic
> number of options, it does sometimes seem that ease of use and
> simplicity take a back seat. Again, only going by my experience, but
> I've had the SB2 for going on a year now, and my wife still can't get
> the hang of it. She's far from a techie, but she still prefers to take
> 5 CDs from their cases, put them in the player and hit shuffle... This
> is as opposed to our Tivo, which, in a sense, is a similar type of
> device. She took to that very easily, and now couldn't live without it.
> There is something to be said for ease of use.
>
> Sorry about the threadjack there, but it was just a bit discouraging to
> see a couple of posts with folks disparaging 'average users' who may not
> live and breath this stuff and want to spend every waking moment
> fiddling with it...
....

The harshness is not towards "average users" at all, for I fully
understand their motivations. One's spouse, roommate, uncle, &c doesn't
learn how to use a certain technology because they don't need to or want
to, and that is fine -- there are certainly plenty of things that all of
us choose not to learn. What I am personally harsh towards is people who
trot out the "average users" straw man argument in support of whatever pet
feature they want. A non-Perl server, a native interface, non-transcoded
support for 17 bazillion codecs, a different screen, a TV interface, blah
de blah. All of it is questioned for validity at some point, and at some
point the idea's defenders come out with "but it's necessary for the poor
average user!"

No, it isn't. If the user wants to use the product, they will learn to do
so. It really isn't that difficult for anyone who's met the prerequisites
of having a computer, a collection of digital music, and a stereo.

I must admit that I'm particularly sensitive to this line of fallacious
argument as I've spent many years on Linux help lists, where it is trotted
out for a turn in the spotlight about once per hour. This list is still at
the once per day level, which is arguably good. Oh, one more thing while
I'm still in rant mode -- anyone planning to hit the Soundbridge button
while playing their average user tune would be advised to visit
http://www.rokulabs.com/forums/ -- hit search, type in "average user", and
enjoy the same arguments. I particularly enjoy that the first thread is
about transcoding :)
--
Jack At Monkeynoodle.Org: It's A Scientific Venture...
"Believe what you're told; there'd be chaos if everyone thought for
themselves." -- Top Dog hotdog stand, Berkeley, CA

Christian Pernegger
2005-12-18, 10:15
> I'm not sure what the harshness towards 'average users' is all about.

No, "average users" are fine :) It's just that generalisations like
"the average user this, the average user that" serve no purpose when
arguing a point. There is no such person as the average user, even if
there were we couldn't know other people's wishes.
If you want to advocate a feature, tell us _why_you_ need it, not that
other people surely must need it.

That aside, my non-technical friends do fine with the SB's own
interface (remote), less so with the web interface. I can assure you
they don't know the difference between transcoded and native tracks,
neither in theory nor in practise.

C.

Listener
2005-12-18, 11:38
I've been following this thread and finding that it makes me uncomfortable.

I've got a large collection of classical music and need to get a good solution that handles the various problems of finding and playing classical music and that solution needs to scales to more than 1500 CDs. I've been trying everything I can including Slimserver/Softsqueeze before I took the plunge. Recently, I participated in two threads that produced several feature enhancement requests (2696-2701) to make it easier to browse and search classical music. Thanks, Ceejay! So I certainly relate to the new user asking for an enhancement.

However, I am a retired software engineer and found the enhancement request to be wrong-headed. It does not work well for a novice to ask for a specific enhancement without detailing his problem with the current system. When that request is not based on a clear understanding of how Slimserver works or the distinctions between file formats, it just leads to chaos and hard feelings.

It works much better for a novice to clearly describe the problems they are having and what they are trying to achieve. He or she should leave room for more solutions thasn the one he can imagine from a limited understanding. Sometimes the solution may require an enhancement but in other cases, the solution may just involve using the system in a different way.

Using a low-end NAS box to run Slimserver does need some clarification by SlimDevices. Reviews and positive mentions of Squeezebox in various forums usually include the possibility of running Slimserver on a NAS box and being able to play music files without having a PC running. I'm sure that many people investigate that possibility in deciding whether to buy a Squeezebox. There are lots of people commenting on using a NAS on this forum but the advice isn't consistent and it appears to me that few people takes responsibility for what they say. If I buy a 1 terabyte NAS server and find that Slimserver doesn't work smoothly or the version supplied by the NAS vendor has problems, I may have wasted $ 1,000 or more on the NAS box.

Slimdevices needs to give clear specs and clear documentation about running Slimserver on a NAS box to avoid confusion and customer disappointment.

Bill

ctbarker32
2005-12-18, 12:43
Hi,

Just wanted to comment on your post about using a $1000 NAS box as a dedicated Slimserver. In my experience, you don't need to spend anywhere near that amount. I'm a brand new SB3 owner and I just built a brand new Slimserver linux box for well under $300.

I bought from Newegg a shoebox system that included a case preinstalled with motherboard and included a free Athlon Sempron 2600 for $230. All I had to add was a hard disk, memory, and CD/DVD player/recorder. I happened to have bought a Maxtor 200 gb drive during the Christmas rush for $29. I also had 512mb of memory lying around. Also, I had a spare DVD drive. This went together very easily and quickly.

I poked around here and discovered that the free ClarkConnect Home linux server software was a good bet for running Slimserver. A big bonus was that Clarkconnect was setup to run headless from the start so I don't have to have a keyboard/mouse/monitor hooked up once I got things setup. It really came together very simply and easily. Slimserver is running great. Once I set things up, I moved the server near my router in my utility room and powered it up. Everything works great. I installed some unix utilities of scp and putty to allow me direct access to the server from my WinXP box. ClarkConnect sets up default SMB shares that are easily accessed from Windows. I copied over all my WMA and FLAC files and pointed WMP 10 to a mapped SMB share on the ClarkConnect box and I rip new CDs directly to the server. This really was pretty straight forward.

-CB

Ben Sandee
2005-12-18, 12:43
On 12/18/05, Listener <Listener.20914z (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> Slimdevices needs to give clear specs and clear documentation about
> running Slimserver on a NAS box to avoid confusion and customer
> disappointment.


I've never seen SlimDevices actually recommend using a NAS -- let alone
specific hardware. There are plenty of people trying to do it -- many of
them successfully. As far as I know they are simply benefiting from the
open SlimDevices architecture that allows the software to run on their
systems but they are doing so at their own risk, in that it is mostly up to
the community to maintain support for these platforms.

Ben

samlw
2005-12-18, 12:46
However, I am a retired software engineer and found the enhancement request to be wrong-headed. It does not work well for a novice to ask for a specific enhancement without detailing his problem with the current system. When that request is not based on a clear understanding of how Slimserver works or the distinctions between file formats, it just leads to chaos and hard feelings.
Bill
Just to clarify...I started this thread. I am no novice. I am a 20-year software engineering veteran. I have worked for many years for companies like Apple and Adobe - companies that strive very hard to "get it right" when it comes to usability. And I feel that I was quite clear in describing the problem I would like to see solved, namely:

a way to have a single centralized library of my digital music in a single high-quality compressed (both on disk and over-the-wire) format (preferably losssless, definitely not MP3), that lives on a low-power Linux box, and that can be accessed and played by both iTunes clients and Squeezebox clients without need for intermediate server-side transcoding.

I really don't see what is so incredibly controversial or "wrong-headed" about this request. To be fair, I understand that this could be solved equally well by Apple if they would simply add FLAC support to iTunes. It could also be solved by SlimDevices if they would license Apple Lossless and include it in their firmware. As a customer of both Apple and Slim, I really don't care how the problem is solved. (Well, maybe I have a slight preference for FLAC - open standards and all.) I would just like it solved...

Ben Sandee
2005-12-18, 12:48
On 12/18/05, ctbarker32 <ctbarker32.2093wz (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> Hi,
>
> Just wanted to comment on your post about using a $1000 NAS box as a
> dedicated Slimserver. In my experience, you don't need to spend
> anywhere near that amount. I'm a brand new SB3 owner and I just built a
> brand new Slimserver linux box for well under $300.


You might have to spend that much for a 1TB server though. :-)

Ben

Mitch Harding
2005-12-18, 13:16
On 12/18/05, samlw <samlw.2094dn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> A WAY TO HAVE A SINGLE CENTRALIZED LIBRARY OF MY DIGITAL MUSIC IN A
> SINGLE HIGH-QUALITY COMPRESSED (BOTH ON DISK AND OVER-THE-WIRE) FORMAT
> (PREFERABLY LOSSSLESS, DEFINITELY NOT MP3), THAT LIVES ON A LOW-POWER
> LINUX BOX, AND THAT CAN BE ACCESSED AND PLAYED BY BOTH ITUNES CLIENTS
> AND SQUEEZEBOX CLIENTS WITHOUT NEED FOR INTERMEDIATE SERVER-SIDE
> TRANSCODING.
>
> I really don't see what is so incredibly controversial or
> "wrong-headed" about this request.


The only part I find strange is that you are willing to accept a lossy
format (such as AAC, the one you are currently using) but unwilling to
accept MP3 (the de facto standard).

I've read where you say that you prefer AAC over MP3 and that it is your
belief that for a given bitrate, AAC offers beter audio quality than MP3.
I've never done any side-by-side comparisons, so I don't know if this is
true or not. But even if we grant that it is, then just encode your mp3s at
a higher bit rate than you'd ordinarily use with your AAC files. Wouldn't
that solve your problem? The extra disk space would not be significant.

I agree with Sean -- most people who are going to be keeping their music
libraries in AAC will probably be using a Mac server, in which case this is
not an issue. Your case is not that common, using a non-Mac server to serve
AAC -- and moreover using a server with such low horsepower that you don't
consider transcoding an option.

It's my opinion that there are higher priority improvements that Slim
Devices could implement. This particular improvement would not be trivial
to implement, according to SD, and it would benefit a very small minority of
users. Surely you can acknowledge the wisdom in focusing on improvements
that will benefit the most users?

All of this having been said, I think some people were unduly harsh in their
replies to you. Your request isn't unreasonable, there are just many higher
priority items ahead of it.

Mitch

danco
2005-12-18, 14:13
On 18/12/05 at 11:46 -0800, samlw wrote
>It could also be solved by SlimDevices if they would
>license Apple Lossless and include it in their firmware.

As has been said before (many times now), at present Apple will not
licence Apple Lossless (ALAC).
--
Daniel Cohen

samlw
2005-12-18, 15:37
On 12/18/05, samlw <samlw.2094dn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> A WAY TO HAVE A SINGLE CENTRALIZED LIBRARY OF MY DIGITAL MUSIC IN A
> SINGLE HIGH-QUALITY COMPRESSED (BOTH ON DISK AND OVER-THE-WIRE) FORMAT
> (PREFERABLY LOSSSLESS, DEFINITELY NOT MP3), THAT LIVES ON A LOW-POWER
> LINUX BOX, AND THAT CAN BE ACCESSED AND PLAYED BY BOTH ITUNES CLIENTS
> AND SQUEEZEBOX CLIENTS WITHOUT NEED FOR INTERMEDIATE SERVER-SIDE
> TRANSCODING.
>
> I really don't see what is so incredibly controversial or
> "wrong-headed" about this request.


The only part I find strange is that you are willing to accept a lossy
format (such as AAC, the one you are currently using) but unwilling to
accept MP3 (the de facto standard).
I've read where you say that you prefer AAC over MP3 and that it is your
belief that for a given bitrate, AAC offers beter audio quality than MP3.
I've never done any side-by-side comparisons, so I don't know if this is
true or not. But even if we grant that it is, then just encode your mp3s at
a higher bit rate than you'd ordinarily use with your AAC files. Wouldn't
that solve your problem? The extra disk space would not be significant.

Yes, well as I mentioned earlier, I am resigned to using MP3, which I will encode at the highest bitrate available. At this bit rate, AAC would still be preferable.


I agree with Sean -- most people who are going to be keeping their music
libraries in AAC will probably be using a Mac server, in which case this is
not an issue. Your case is not that common, using a non-Mac server to serve
AAC -- and moreover using a server with such low horsepower that you don't
consider transcoding an option.

True. But I only asked for AAC because I was looking for a better alternative to MP3. If you go back to the start of the thread, you will see that I was under the incorrect impression that Apple Lossless and AAC were essentially the same codec. What I really wanted was Apple Lossless, so the title of this thread is a bit unfortunate (my fault). Still, if Apple Lossless is not possible, AAC would be my second choice.


It's my opinion that there are higher priority improvements that Slim
Devices could implement. This particular improvement would not be trivial
to implement, according to SD, and it would benefit a very small minority of
users. Surely you can acknowledge the wisdom in focusing on improvements
that will benefit the most users?

Absoultely. I'm not trying to dictate Slim's priorities and I never said that this should be moved to the top of Slim's priority list. I'm just a user with a request, and this forum seems like the place to make it. That said, Squeezebox's main competing product (there I go pushing that button again) does support AAC in firmware. I assume it does so because there is market demand for such a feature. So, I wouldn't rush to judgment that my situation is so terribly uncommon. As I said before, I think that the Squeezebox is a great product - superior in most respects to its competitors (which is why I chose it). I also happen to think that in this one respect, it is not superior. And so in the interest of keeping Squeezebox at the head of the pack, I humbly suggest that Slim look into adding Apple Lossles or at least AAC to the Squeezebox's native format repertoire.


All of this having been said, I think some people were unduly harsh in their replies to you.
Agreed. And I think we've all beat this horse just about to death. So, 'nuff said.

fuzzyT
2005-12-19, 13:37
samlw wrote:

> I think high-bitrate MP3 is the way I will have to go. In my
> experience, AAC sounds better and compresses better than MP3 at a given
> bitrate. So I have a personal preference for AAC over MP3.

(Assuming you're happy with lossy...) As you climb the bitrate ladder,
at some point either codec will get you to an acceptably good sounding
encoding. And the resulting files will probably be with 10-15% size of
one another. So, is it really material if AAC got there at a lower
average rate?

Just for compatibility's sake, give MP3 a real shot. Head over to
hydrogen audio and find the latest recommended encoder and settings.
Play around with it and see what you think. You may be surprised.

--rt

Darren
2005-12-19, 17:33
I for one, would like to see native AAC support. Not for the increased performance, but the ability to fast forward or rewind through a song.

Marc Sherman
2005-12-20, 05:47
Darren wrote:
> I for one, would like to see native AAC support. Not for the increased
> performance, but the ability to fast forward or rewind through a song.

So in fact, what you'd like to see is the ability to FF or REW through
AAC songs. This could be implemented without native AAC support. In
fact, I'm pretty sure it could be done entirely in the (open source) server.

- Marc

Christian Pernegger
2005-12-21, 10:02
> And I feel that I was quite clear in describing the problem I would like to see solved,
> namely:
>
> A WAY TO HAVE A SINGLE CENTRALIZED LIBRARY OF MY DIGITAL MUSIC IN A
> SINGLE HIGH-QUALITY COMPRESSED (BOTH ON DISK AND OVER-THE-WIRE)
> FORMAT (PREFERABLY LOSSSLESS, DEFINITELY NOT MP3), THAT LIVES ON A
> LOW-POWER LINUX BOX, AND THAT CAN BE ACCESSED AND PLAYED BY BOTH
> ITUNES CLIENTS AND SQUEEZEBOX CLIENTS WITHOUT NEED FOR
> INTERMEDIATE SERVER-SIDE TRANSCODING.

The COMPRESSED does not matter from a user perspective, at least not
if you don't specify how much compression you'd like, for example in
hours of music per GB.

The WITHOUT NEED FOR INTERMEDIATE SERVER-SIDE TRANSCODING is not part
of the problem but part of your proposed solution. It's most of the
time better to keep the two apart.

> To be fair, I understand that this could be solved equally well by Apple if they would
> simply add FLAC support to iTunes.

Sounds good. Since you worked for them, just call up a contact and
lobby a little.

> It could also be solved by SlimDevices if they would license Apple Lossless and include
> it in their firmware.

I'd rather the next SB would not be even more expensive. I don't like
paying for licenses I'll never use, and I don't like to support stuff
that uses closed file formats. WMA in the SB3 is bad enough, really :)

C.

Christian Pernegger
2005-12-21, 10:05
Maybe you should support the request for native DRMed AAC playback in
the SB. That's something that can't be done today even with
transcoding, would make the iTMS crowd happy and gett you your AAC
support to boot. It's all in the wording.

C.

P Floding
2005-12-23, 08:30
Hi,

Are there plans to add native AAC support to the Squeezebox? Not the DRM version - just plain AAC. I bought my Squeezebox expecting to be able to have a central music library accessible by both iTunes and the Squeezebox via SlimServer. However, I want to store the music uncompressed. So this rules out MP3, which seems to be the only common denominator format between iTunes and SlimServer.

FLAC is not supported by iTunes. And AAC is not directly supported by SlimServer. (And no, I don't want to install extra software modules like LAME to convert my uncompressed music to "high quality MP3!")

Why doesn't the Squeezebox simply support AAC in firmware? Is there a licensing issue? The Roku SoundBridge products have such support as far as I can tell...

Thanks,

Sam

In response to this post, and other later posts by yourself, and possibly others (if I got them mixed up), I'd like to say the following:

1. AAC is not lossless (normally). Does even Apple support lossless AAC?

2. My ultralight laptop, running at 500MHz, manages to transcode 224kbit AAC and route it via a 11Mbit/s wifi to the SB3, which is also on the same wifi network. I can't imagine what underpowered server can't manage the same? Are you perhaps transcoding to another lossy format, rather than AIFF? Or is the server under load from spyware or other demanding things?

3. Transcoding one lossless format to another must be even less demanding than transcoding 224 kbit AAC like I'm doing.

4. Implementing some way of seeking through transcoded material would be a good idea. Personally I would be happy with a way to move a marker through a bar representing the song. (Like on the iPod). Being able to actually hear anything while moving is almost useless anyway, I think -and is what would be the hard part to implement, I believe.

Please excuse me if some of the things I have commented on were actually related to other peoples postings!

Regards, and happy holidays!

seanadams
2005-12-23, 10:13
1. AAC is not lossless (normally). Does even Apple support lossless AAC?


Lossless AAC (aka MPEG 4 ALC) is not widely used at all. Apple does not support it AFAIK, and it is not the same as Apple Lossless.



2. My ultralight laptop, running at 500MHz, manages to transcode 224kbit AAC and route it via a 11Mbit/s wifi to the SB3, which is also on the same wifi network. I can't imagine what underpowered server can't manage the same?


NAS disks often have very weak processors - just enough to move files around. Often they're 200MHz or less, without the necessary memory / CPU cache / ALU to run codecs. Lossless maybe, but lossy codecs can be quite heavy unless they're tuned for the architecture.



3. Transcoding one lossless format to another must be even less demanding than transcoding 224 kbit AAC like I'm doing.


Correct.



4. Implementing some way of seeking through transcoded material would be a good idea. Personally I would be happy with a way to move a marker through a bar representing the song. (Like on the iPod). Being able to actually hear anything while moving is almost useless anyway, I think -and is what would be the hard part to implement, I believe.


Agreed. Patches welcome if anyone wants to have a crack at it.

P Floding
2005-12-23, 14:47
NAS disks often have very weak processors - just enough to move files around. Often they're 200MHz or less, without the necessary memory / CPU cache / ALU to run codecs. Lossless maybe, but lossy codecs can be quite heavy unless they're tuned for the architecture.

OK, thanks for the info!
I wasn't aware of this, and in this case such machines are probably not really suitable to run real server-side software such as Slimserver. (Which has a working set of 35MB, and total usage of 55MB on my XP-machine.)
Anyway, it would be unfair to demand or even expect that it works!

ianr
2009-03-25, 20:11
Hi,

Now that AACPlus is the defacto for iTunes purchases, has there been any thought given to implementing either native support or at the very least FF/RW functionality for these files?
I really don't want to transcode the files to mp3 (quality loss) or flac (takes up additional space and no SQ benefit). Like it or not, iTMS is the largest online music source, so surely it makes sense to extend the support, no?

agillis
2009-03-25, 21:12
Support for various music encoding formats is one of SqueezeCenters strengths. Because SC is extensible Plugins can make it support any type of file. Unfortunately most NAS systems don't have the processing power to handle plugins and transcoding. This is why I created VortexBox to allow the playing of all types of files and the widest support of plugins.

If you really want to use apple files I would recommend VortexBox. If you have Apple file with DRM you will need to play them on an Apple Device.

Ron F.
2009-03-25, 22:07
Where I use AAC and AAC+ is not in my own library, but streaming internet radio stations to my SB3. My own library is in FLAC of course.

awy
2009-03-26, 02:52
Now that AACPlus is the defacto for iTunes purchases, has there been any thought given to implementing either native support or at the very least FF/RW functionality for these files?


SC 7.3.3 will come with AAC/AAC+ support out of the box, using server-side transcoding using faad2. There will not be native codec support in the players: there is no more space in the firmware.

Unfortunately, there will not be FF/RW support in this release. Note that this issue is independent of native codec support as FF/RW functionality is always implemented in SC, not the player.

gorman
2009-03-26, 04:49
I wonder what's the reasoning behind keeping Vorbis native and transcoding AAC. While I don't use AAC at all and use Vorbis for portable needs... I don't doubt that the market would far prefer the opposite solution.

funkstar
2009-03-26, 05:06
I wonder what's the reasoning behind keeping Vorbis native and transcoding AAC. While I don't use AAC at all and use Vorbis for portable needs... I don't doubt that the market would far prefer the opposite solution.
Some idle speculation:
• Perhaps the AAC/AAC+ decoder would be far larger than the Ogg decoder, so there still wouldn't be space.
• Ogg has issues in the amount of memory it uses, especially with lower than 64bit recordings. Perhaps this is the same with AAC/AAC+? and if that's the case, broken native support is going to cause more problems than no native support will.
• Perhaps, even with a bug free codec in the firmware, there isn't enough processing power in the SB3/Receiver/Boom to run everything and decode AAC/AAC+
• There is also the time/cost factor in implementing this codec in the firmware. I think the Ogg codec was a fairly simple port as various decoders are readily available as it is. AAC/AAC+ might need extensive reworking from faad2 to make it compatible with the Ubicom processor. I believe it doesn't have a floating point unit, so only integer maths is available. This heavily restricts what a codec can do.

So as you can see, there are plenty of possible reasons why AAC/AAC+ and ALAC aren't included in the current lineup of players. Perhaps adding codecs to some future player will be trivial, and everything will be supported natively, who knows!

:)

gorman
2009-03-26, 05:09
In fact, I was simply wondering. Never thought there were no reasons. Also, it could well be that, back then, with the grand majority of AAC music being DRMed, SD thought useless to implement it natively.
The market, in this regard, has changed significantly.

DoomWolf
2009-03-26, 07:49
I believe Spotify uses Ogg Vorbis for its streams, so there's a potential larger use for Vorbis in the future.

Nonreality
2009-03-26, 18:57
My own library is in FLAC of course.

Of course, of course. I'm sure no one here would think that you would use any of those other lowly formats. Just think of the humiliation if that wasn't so. :)

Nonreality
2009-03-26, 19:07
I think high-bitrate MP3 is the way I will have to go. In my experience, AAC sounds better and compresses better than MP3 at a given bitrate. So I have a personal preference for AAC over MP3.
From my experience and readings on hydrogenaudio.org what you are saying is true up to about 160kbs. When you get into the higher bit rates you really can't tell any difference between mp3, ogg or aac. There may be differences in size but it's really not much at all. Try it and see. A 256 mp3 is going to sound every bit as good as a 256 aac or ogg.

pfarrell
2009-03-26, 19:29
Nonreality wrote:
> A 256 mp3 is going to sound every bit as good as a 256 aac or ogg.

A flac file, lossless and all that, is only about 700kbs. So any 256kbs
is not all that compressed.

Its the ten to one compression that sounds terrible.

--
Pat Farrell
http://www.pfarrell.com/

probedb
2009-03-27, 07:01
Its the ten to one compression that sounds terrible.


To you at least.

Am currently at -V3 with LAME and can't tell the difference with the source for most tracks.

jeremygray
2009-03-28, 10:04
To you at least.

Am currently at -V3 with LAME and can't tell the difference with the source for most tracks.

To you at least. :)

I can hear the compression artifacts in any MP3 or AAC bitrate (even 320). Too many years of music training, I suppose. Also makes it a nightmare to listen to off-key vocals (though tuned vocals drive me even crazier :D), lazy drummers ("OMG! These hi-hat 16ths are too fast! I'd best slow down the entire band for this section of the song!"), etc.

Suffice it to say that there really are only two safe recommendations us users can make to one another: 1. keep a losslessly-compressed copy of your sources somewhere so you can recompress at will. 2. Use whatever lossy format/rate works for _your_ears_.

Back to AAC for a moment: Bring on the FF/RW! I've just started with Squeezcenter recently and haven't yet done all my various transcoding to work with it best. In the meantime, I'd love to be able to seek within my AAC files.

Nonreality
2009-03-28, 12:54
It's a nightmare for you to listen to but you still use AAC?

Ron F.
2009-03-29, 22:20
Of course, of course. I'm sure no one here would think that you would use any of those other lowly formats. Just think of the humiliation if that wasn't so. :)

It would be awful! I can't bare to think about it.

Ron F.
2009-03-29, 22:31
From my experience and readings on hydrogenaudio.org what you are saying is true up to about 160kbs. When you get into the higher bit rates you really can't tell any difference between mp3, ogg or aac. There may be differences in size but it's really not much at all. Try it and see. A 256 mp3 is going to sound every bit as good as a 256 aac or ogg.

Personally, I find 64K MP3 to be truly awful - I have to turn it off. 128K WMA or AAC to be listenable for an extended period of time, if not equivalent to a quality FM broadcast. 192K - any format - to be hard to distinguish from lossless. So, when making compressed files - I opt for 192K Vorbis.

-Ron

MrSinatra
2009-03-29, 22:38
i do 256kbps mp3s, lame 3.96.1 and higher, at -q1

i don't believe i could reliably tell the difference between them, and a CD, in a proper double blind test, and i'd be willing to bet most people here couldn't either.

in fact, if the mp3s were just a wee bit louder than the cds, i bet they'd pick the mp3s all day long... (due to a psychoacoustic effect where the ear prefers louder sound)

even if someone could tell the difference reliably, in order to do so, you'd need the best equipment AND environment to do so, and the further question would be HOW MUCH BETTER is the difference? meaning, how would you quantify/qualify it?

for most peoples purposes, that are less than ideal, i think a HQ mp3, such as mine, more than suffice. (i would agree however, that there are other good reasons to use FLAC, or what have you...)

jeremygray
2009-04-04, 09:39
It's a nightmare for you to listen to but you still use AAC?
I think you might have misread me. I said that music training makes it a nightmare to listen to off-key vocals, etc. I also said that I can hear compression artifacts in any lossy encoding at any rate I've tried (and even a few that are out-of-spec.) I didn't say that AAC is a nightmare to listen to. :)

That aside for the moment, the only reason I even use AAC is because it is the most sonically transparent of the lossy options available for a reasonable number of portable players. Were iPods to have tens of gigabytes upon tens of gigabytes of solid-state storage I'd be off of AAC and using only lossless faster than you could say Go! :D