Bluetooth Enabled iPods?

[sinisterdesign]

like this -> http://griffintechnology.com/products/airclick/ ?

just found it. theres one to go into a usb port on ur mac/pc, then u can control itunes wirelessly away from ur computer. i would think it would work with ur Airport express wouldnt it?

YEAH, a lot like that! thx. i KNEW someone had to be working on it. i couldn't imagine that it would take a rocket scientist to figure out how to do it (just someone smarter than myself).

"preorder". hmm, i wonder what kind of timeframe they're looking at? ahhh, the FAQ:

When will AirClick ship?
AirClick for iPod, AirClick mini, and AirClickUSB will be available in May, 2005. However, you may pre-order the AirClick package of your choice in our online store.​

i was HOPING Apple would come out w/ their own version of this (especially after steve's sly grin at the announcement of AxP when asked about a remote), but Griffin seems to be on the spot w/ all kind of iPod accessories lately.

 

[sinisterdesign]

At least Bluetooth 1.0 transfer speeds are faster than floppy disk transfers.

yes, and to this day i STILL get shcked looks from my PC coworkers that i don't have (nor have i in YEARS) a floppy drive on my computer.

i say, "let's see, 'floppy drive', ahh yes, that was right before i got a Zip drive, which was before i got a Jaz drive, which was somewhere before i got a CD burner, which was a little while before i got a DVD burner which was somewhere within this CENTURY."

 

[qzak]

another remote

i was HOPING Apple would come out w/ their own version of this (especially after steve's sly grin at the announcement of AxP when asked about a remote), but Griffin seems to be on the spot w/ all kind of iPod accessories lately.

sinisterdesign - apple advertises another version, an infrared one, by Keyspan right on the Airport Express webpage. Keyspan Express Remote theres the link.

personally i think the first one looks better than this infrared one.

 

[sinisterdesign]

sinisterdesign - apple advertises another version, an infrared one, by Keyspan right on the Airport Express webpage. Keyspan Express Remote theres the link.

personally i think the first one looks better than this infrared one.

oh excellent! i guess before i whine, i should check out the new products on the market, huh?

this Keyspan remote is the exact idea i had in mind on how this would work: IR to receiver–>USB–>802.11–>computer–>iTunes. i guess the drawback is the limit of having to be line-of-sight w/ the IR remote as opposed to the RF remote of Griffin.

i like the look & functionality of Keynote's (the "iTunes mode" and programmable buttons are nice), but the range of Griffin's is a point in it's favor. where i really need it is on the 2nd floor of my loft, so i would never be too far from the AxP module at any given time.

maybe i'll wait & read some reviews on ipodlounge.

thanks for the links, guys!!!

 

[matticus008]

I'm glad to see the discussion back on topic. CD quality music is possible under Bluetooth, using the 2.0 specification. This is the method that the iPod will implement, especially since Apple's line has already started the 2.0 switchover, and Motorola and other companies are preparing 2.0-compatible headsets. Yes, CD audio is 1411kbps in quality, which is ~176kB/sec. That exceedes the maximum data rate for BT 1.1 by about 100%. The beauty of BT 2.0 is that it provides more than four times that transfer of 1.1, and therefore more than double what we need for CD-*quality* audio. However, no one actually wants to play an audio CD over bluetooth, which is why the CD bitrate got off track over a comment that "CDs play at 150K/sec" which is indeed the data rate for the CD-ROM specification, of which audio CDs are a member. No, 150K/sec is not enough for an audio CD to play. However, most iPod users and computer users in general are not accustomed to thinking in bits. Look at your downloads in IE, Firefox, or really any browser. You'll notice transfers indicated in kB/sec--that's right, bytes. Connections and bandwidth are referred to in raw terms of bits, so your broadband connection is probably 1.5 or 3Mbps. 3Mbps matches the BT 2.0 +EDR specification and is about the same as your broadband connection. Have you ever tried to stream typical 128kbps music purchased from iTunes over that internet connection, say from your home to a friend's house? And that there's still plenty of space in that connection (even at 1.5Mbps) to use the internet effectively? Then you know that if BT 2.0 works out, it should handle this with a minimum of problems.

Now, since most people don't work with bitrates or bits at all, the discussion is centered on how much data needs to pass through the BT hardware every second in order to stream the data. Now, let's say that you actually want to transfer raw, uncompressed CD - quality music over bluetooth. Why? I don't know. But you need to move more than 176 kilobytes of data every second to achieve this. However, since most people know the length of songs and the file size, it's easy to divide the size by the length in seconds and make sure that your audio comes out to less than 200kB or maybe 250kB per second to fit comfortably in the Bluetooth stream. Since most music is compressed and downsampled at anywhere from 128-320kbps, while preserving good quality, Bluetooth 2.0 should be able to handle this without any strain on a clean connection. It should even handle the raw CD data at 1411kpbs, easily fitting within the 3000kbps maximum transfer. Because of MP3 and AAC compression, you can't compare bitrates completely, because the bitrate doesn't represent the filesize accurately.

So that said, BT 2.0 can handle up to about 375kB of data every second under a theoretical maximum. Because we haven't seen the real performance yet, I'm being conservative and suggesting a maximum throughput of 200 kilobytes every second. Now, because we aren't talking about playing an audio CD on a bluetooth connection, but playing a digital music FILE over BT, we have to figure out if our music will play by dividing the file size of some typical pieces by their length in seconds. Whether the bitrate is 128kbps or 1411kpbs, the iPod has to take the file and stream it digitally over the bluetooth connection, and it has to fit within BT's capacity to carry data. That's why comments referring to download speeds in kilobytes are more practical.

Here's an example file: 320kbps MP3 with a size of 13.1MB and a length of 5:44 (344 seconds): About 38 kilobytes of data per second (roughly 2.2 megabytes per minute). Under BT 1.1, a sustained 38kB/sec transfer is almost impossible, and you need to run more than this to buffer the connection (we'll say double). That's 76kB every second. Does anyone get that kind of sustained bluetooth performance? Probably not. But we should get that pretty easily with 2.0+EDR. That same file in native uncompressed 1411kbps is 73.5MB or so (or 213 kilobytes of data per second of music), and if you do the math, as Napster says, the MP3 file is smaller than it would be if the bitrate determined the file size.

 

[matticus008]

oh excellent! i guess before i whine, i should check out the new products on the market, huh?

this Keyspan remote is the exact idea i had in mind on how this would work: IR to receiver–>USB–>802.11–>computer–>iTunes. i guess the drawback is the limit of having to be line-of-sight w/ the IR remote as opposed to the RF remote of Griffin.

i like the look & functionality of Keynote's (the "iTunes mode" and programmable buttons are nice), but the range of Griffin's is a point in it's favor. where i really need it is on the 2nd floor of my loft, so i would never be too far from the AxP module at any given time.

maybe i'll wait & read some reviews on ipodlounge.

thanks for the links, guys!!!

Wow! This is what I've been looking for, too! This is a really great find.

 

[MacSlut]

matticus008,

That's probably the longest explanation I've ever seen in terms of describing if a Bluetooth enabled iPod could stream audio at various bitrates...I'm supposed to be the long winded one

I do agree with you for the most part...at least in terms of what a Bluetooth iPod would support. I believe my math is simpler *and* more precise.

Browsers show data transfer in bytes because that is the unit of measurement that people are dealing with for the original file. Your browser will show say a 10 megabyte file and tell you how many bytes are being transferred, which makes sense.

On the other hand, how many people could tell you what rate in bytes they encode audio at (or video for that matter)? How many people off hand could tell you what the file size and length in time most of their MP3/AAC library is?

Most people (and most software) will encode at 128kbps - 320kbps (more or less). So determine whether or not any file of any kind (video or audio) will stream real-time, all you need to do is compare the bitrate of the encoding to the bitrate of the transmission protocol. There's no need to look at the size of the file or the amount of time.

Bluetooth 1.x is far too slow, but as you point out Bluetooth 2.0 is 3,000 kbps per second. Bluetooth has a very high overhead (27%) due to channel scanning and so forth, but even with a 50% overhead for Bluetooth 2.0, 1,500 kbps is going to easily handle 128kbps files that the iTMS offers and 1,411kbps that would be the maximum data rate for any song file on an iPod...specifically uncompressed 16 bit 44.1 stereo files (true CD quality).

 

[matticus008]

matticus008,

That's probably the longest explanation I've ever seen in terms of describing if a Bluetooth enabled iPod could stream audio at various bitrates...I'm supposed to be the long winded one

I do agree with you for the most part...at least in terms of what a Bluetooth iPod would support. I believe my math is simpler *and* more precise.

Browsers show data transfer in bytes because that is the unit of measurement that people are dealing with for the original file. Your browser will show say a 10 megabyte file and tell you how many bytes are being transferred, which makes sense.

On the other hand, how many people could tell you what rate in bytes they encode audio at (or video for that matter)? How many people off hand could tell you what the file size and length in time most of their MP3/AAC library is?

Most people (and most software) will encode at 128kbps - 320kbps (more or less). So determine whether or not any file of any kind (video or audio) will stream real-time, all you need to do is compare the bitrate of the encoding to the bitrate of the transmission protocol. There's no need to look at the size of the file or the amount of time.

Bluetooth 1.x is far too slow, but as you point out Bluetooth 2.0 is 3,000 kbps per second. Bluetooth has a very high overhead (27%) due to channel scanning and so forth, but even with a 50% overhead for Bluetooth 2.0, 1,500 kbps is going to easily handle 128kbps files that the iTMS offers and 1,411kbps that would be the maximum data rate for any song file on an iPod...specifically uncompressed 16 bit 44.1 stereo files (true CD quality).

Right on. I'm glad we got that worked out (and with more clarity on the details than 99% of people care about ). Of course, the reason I used the complicated math is to illustrate the file size constraints of Bluetooth and to imply that even with 4x faster transfers, you still won't want to sync your iTunes library with BT (going after two arguments with one lengthy reply--efficiency!).

At least the forum members that read patiently now have a lot more insight into transmission conversions and normatives and probably learned a thing about CD audio along the way

 

[combatcolin]

MacSlut.

You do not say that an car (for eample) is 170cm high or whatever you would say 1.7M

Describing a file in terms of its size in bits can be horribly confusing as you have to do the sums to figure out its real size.

When people know the size of a picture is 100K they know exactly how big ot is.

Now if your a programmer who needs to track the size of code et then yes bits or kilobits is more acurate but for the everyone else on this planet good old KB will do.

 

[Porchland]

Apple store

Does the Apple Store usually go down at 9 a.m. ET or 10 a.m. ET when there's new product?

 

[AidenShaw]

common use

MacSlut.

You do not say that an car (for eample) is 170cm high or whatever you would say 1.7M.

On the other hand, my skis are officially sold as 185cm - so your claim isn't absolute, it is not uncommon to use "cm" for lengths over 100 cm. (Or milli-litre for volumes over a centi-litre, or gram for masses over a deca-gram or hecto-gram.)

Don't forget about "deci" as well, deci-litres and deci-metres exist - but are not often used.

(extra hyphens for clarity....)

When people know the size of a picture is 100K they know exactly how big ot is.

Right, it's 800Kb ....

Note that when you say the picture is 100K, you are saying that it is very cold - not how big it is. But, common use is often clearly understood even though it is technically incorrect.,

 

[MacSlut]

MacSlut.
You do not say that an car (for eample) is 170cm high or whatever you would say 1.7M

Right, just like instead of saying 3,000 kbps, you would say 3 mbps. Using your example like was done with the CD, it would be like saying 50 inches because we (in the US anyway) relate more with inches. However the problem with this is that the thing we're comparing it to is also in centimeters and furthermore 170cm isn't 50 inches, it's 66.9291339 inches. (Just like 1411 kilobits isn't exactly 176 kilobytes).

Don't get me started on why we should go metric...strike that, don't get me started on anything

Describing a file in terms of its size in bits can be horribly confusing as you have to do the sums to figure out its real size.

Right, I agree with that. I did say that storage is usually referenced in bytes. This is because a byte is the smallest unit that makes up a file...in the sense that you can't have a file that is 100,000.1 bytes (at least not on the systems we're using). You can on the other hand have a bit rate that is not evenly divisible by 8...in fact, CDs do not play at a rate that is exactly bytes/seconds divisible.

When people know the size of a picture is 100K they know exactly how big ot is.

True, but they know nothing of the speed required for the file to play in real time (stream).

Try this experiment today: Ask people how they encode their MP3s or AACs. I bet the common answers you will find will be 128kbps, 160kbps, 192kbps, 256kbps, 320kbps...maybe some who don't know, use variable bitrate encoding, or say (the painful to my ears) "CD quality".

What you won't find is someone who will tell you the rate in bytes or the overall file sizes.

Here's another experiment: Look at articles from various major media outlets...CNN, CNET, AP, WSJ, NYT, USAToday etc... See how many of them refer to data communications such as Bluetooth or WiFi in bytes per second.

Note that in addition to the above, Apple refers to both Bluetooth and WiFi speeds in bits per second.

Now if your a programmer who needs to track the size of code et then yes bits or kilobits is more acurate but for the everyone else on this planet good old KB will do.

Sure, if you're referring to a file size or trying to determine how long it will take for a file to download, having your browser tell you how many bytes per second are being downloaded is helpful to the average person, but...

When the given encoding rate is in bits and the given bitrate is in bits, it's not only easier to use bits instead of bytes, but it also happens to be more accurate and follows the common usage of all the major print and media companies.

 

[combatcolin]

Whats wrong wih metric?

The whole world will be eventually, same as the whole world be be a democracy.

Try the UK system, we use both so and sometimes its really gives you a headache sometimes.

Regarding the download measurements, time and time again i've come across people who complain about why there 600K speed never gets anywhere near there.

When i have to explain to them to divide your download speed by 8 they understand and are a little peeved off., ISP's never quite explain it properly.

And as for Kelvin - its a mans name, and is a word used by one of the other guilds of geek.