There was never an option that allowed you to extract bits from a _real_ PJB. The menu option you are talking about was only used in the PJB's simulator (before real hardware or the communications protocol were developed) -- if you were talking to a "simulated" PJB, the mp3 data was represented as local disk files, and then the Extract Track command would copied the bits out.
The C++ class that implemented the "real" communications protocol had an empty function for that command, since there is no communications protocol support and no firmware support for it to use.
When the simulator was removed, we forgot about the right-button context menu (it still had the option). It pops up a window, asks for a file name, calls the appropriate MFC/C++ function, which contains just one line: "return ERR_NOT_SUPPORTED". There's no code there to implement it. There never was, and there still isn't today. The simulator got all the bugs out, so we never needed to put it in a real PJB.
You have *ALWAYS* been able to just upload the MP3s you have. You don't *HAVE* to use the original CDs, but it sure is convenient if you do have them. (The included Jukebox Manager rips, encodes, and transfers in one step... that's what the documentation is trying to say).
One reason to use the Jukebox Manager is it includes Fraunhofer's best encoder. I re-ripped everything I had when I got my PJB working the first time, but the other encoders have improved in the past few years as well.
If you have a bunch of MP3s, just press the "Add stored tracks" button (4th from the left) and point it at the files to upload.
This SDK is for the part of the code that does that. You wouldn't have had to re-rip your hundreds of CDs ever... not even if you had the first PJB.
No, Compaq didn't open-source the whole thing. They can't, since there's lots of licensed material in there that Compaq cannot redistribute.
I did much of the work preparing this kit. It was derived from the actual sources, and it includes the key parts you'll need. The rest of it (the stuff that was not included) is Windows MFC stuff. Does anyone here really want that? I thought not:-).
Maybe I shouldn't have said "In the true spirit of open source..." stuff since I'm not even sure I know what that is myself:-).
I'm hoping people will write some interesting applications with this.
Actually, the motivation for releasing this SDK was from requests from customers for Linux support. It wasn't for any recognition, or even money -- customers asked, that's all!
The researchers working on the original PJB prototypes have been working on other projects lately, and writing *another* Jukebox Manager doesn't exactly qualify as research. So, for all those who asked, this SDK is for you.
(I should know, since I helped get this kit released).
The technology that is in the PJB did not come from Itsy, but both Itsy and the PJB came from Compaq's research labs in Palo Alto, CA.
Itsy is a StrongARM-based handheld Linux machine. The PJB is a Motorola 56309-based music player. Other than the fact that they're both portable and the engineers frequent the same Palo Alto restaruants, they're quite different:-)
The PJB's technology was licensed to a Korean company called HanGo (dba Remote Solution in the US). They resell the PJB via mp3factorydirect.com, in catalogs via Hy-Tek manufacturing (Hammacher-Schlemmer, etc.). I think there are some other distributors now too.
[I worked on the PJB's firmware - it was a way cool project].
It looks like it is creating copies of the song, but it's actually just copying directory entries around. You can even rename the copy you made and then make copies of that, and it's _still_ just going to make links.
The PJB does impose the Set/Disc/Track hierarchy though (something I find mildly annoying but I can live with it). So, all tracks must be in a disc, all discs must be in a set. Usually not a problem though.
Basically, the only way you can eat storage is by ripping CDs or adding MP3s from your hard drive. Everything else is just pointers. One of the many benefits of a custom file system:-).
That picture _was_ an RJ45 jack. Revision 1 PJBs (the first ones that were actually assembled into portable units) had 10MBit Ethernet controllers on them, since we were familiar with the chip and had lots of them in the lab. About 40 of those were built (I still have mine). Many of the photos you see are of rev1 prototypes, because we were using those pictures to pitch the product viability of the PJB.
The choice of Ethernet vs. USB was difficult. There are lots of really good reasons to use Ethernet (easy compatibility with all OSes, good performance, even the possibility of using TCP & HTTP to talk to it:-).
But, there are also good reasons to use USB, and that's because many people do NOT have Ethernet controllers, and it's unacceptable to ask them to install one just for this application. Not every customer is a slashdot regular, so we have to cater to less-geeky consumers. USB is also getting lots of press these days.
I don't regret the decision (it was the right move for the product), but I still like the idea of Ethernet myself.
"Extract Track" never worked on real PJBs - it was used with "simulated" PJBs eons ago before there was real hardware. It manipulated a container file on the local file system.
Yes, the PJB is just a little computer. Sure, someone could reprogram it to spit data back out. The shipping software doesn't have that support, and there's no code in the Jukebox Manager to deal with it.
That extract track command was removed in 1.5.2. When the simulated PJB support was disabled, we forgot to remove the menu from the resource file.
[Gack, forgot to do "Plain text" again. Here it is, formatted the way I wanted to see it. Apologies for the double-post.]
"You must make new ones with included software".
No, No, No. Wrong. Incorrect. Where do people get this misinformation?
I worked on the PJB when it was a research project.
It would not be much of an MP3 player if you couldn't put your own MP3s on it. The Jukebox Manager does have its quirks (they are being worked on) that make it difficult to import huge trees of MP3s, but downloading your own MP3s is right there, the fourth button on the toolbar.
BTW, I get about 7X encoding speed on my 450Mhz PII, using Fraunhofer's very fine encoder. I think that's pretty fast, and the quality of the bitstream is excellent.
"You must make new ones with included software". No, No, No. Wrong. Incorrect. Where do people get this misinformation? I worked on the PJB when it was a research project. It would not be much of an MP3 player if you couldn't put your own MP3s on it. The Jukebox Manager does have its quirks (they are being worked on) that make it difficult to import huge trees of MP3s, but downloading your own MP3s is right there, the fourth button on the toolbar. BTW, I get about 7X encoding speed on my 450Mhz PII, using Fraunhofer's very fine encoder. I think that's pretty fast, and the quality of the bitstream is excellent./Mitch.
2. Macintosh support is being worked on. I'm waiting for clearance to release an SDK for Linux hackers.
3. The encoding is done on the PC, using Fraunhofer's encoder. The MP3 bits are shipped via USB to the PJB.
4. Not including 160kbps was my mistake. I left it out of the table. We'll get that into a future software update.
6. "menu system feels kind of poorly done." Um, care to explain that? How would you do the menus?
8. The disk will only continuously spin if you're continuously pressing buttons to change songs.
9. [browse while playing] - probably the biggest single requested feature. I think you can count on that eventually getting implemented, as I want it myself, and I worked on the firmware.
I'll try to post here if/when I finally get to post the SDK. It will include plenty of information (file system documentation, USB protocol, etc.) and an example program that already runs under Linux. I'm very interested in what the Linux world comes up with for a "Jukebox Manager" equivalent application.
There's no firmware support for retrieving data from the PJB, so the SDK won't help with any digital cracking.
You're right of course, sooner or later more court cases will come out and eventually all this stuff will get straightened out.
I don't think we (a humble research group:-) want to be the the test case. So, technology-wise I think the PJB has a fair compromise.
That said, (my opinion follows) I can't think of any reasons I'd want to extract music data _from_ my PJB. I've had one for 18 months. What I do _NOT_ want is all the wierd "check-in"/"check-out" stuff that some DRM schemes use, like Sony's MagicGate.
Given a choice, I pick write-only anytime. I really don't want to go down the "rights and freedom" rathole, it's pointless. I just want to carry 100+ of my CDs in a small portable device.
The only things in common between the Itsy and the PJB is that they're both designed by Compaq Corporate Research, and they're both portable devices. The researchers on both projects eat at the same restaurants... does that count?:-)
The PJB has a 24-bit Motorola 56309 DSP as its CPU, and the Itsy uses a StrongARM SA1100. The PJB doesn't have an operating system at all (real programmers don't need 'em:-), and the Itsy runs Linux.
The file system was specially designed to prevent problems like that. It _never_ writes the disk when you are just playing back, and there is a special database-style "commit" operation when writing data.
Unless there's a bug in the software, the PJB won't corrupt the disk during power failures or other problems.
It's $800 because it costs a lot of money to tool up a factory, order zillions of parts, pay for an injection-molding tool, etc. Hopefully things will improve.
/Mitch. (who worked on this project when it was a research prototype)
I wrote that FAQ. I also wrote a bunch of the firmware in the PJB (here at Compaq Corporate Research). Not wanting to anger the recording industry is why you can't copy files back. Given a choice between that an SDMI, I pick this any day. Nobody's treating anyone like children... we'd just rather make money and let other people have MP3 players than give it to lawyers. As for Linux... let's see. I work in a research lab. Researchers like Linux. The only thing stopping an SDK from being released (under GPL) is legal stuff from the corporation. It takes more than just documenting protocols and stuff (reverse engineering wouldn't yield the best results) - real example programs derived from the real sources are the best way to get a Linux/PJB GPL effort started. Keep your fingers crossed, I'm hopeful we'll be able to get an SDK out soon./Mitch.
Slashdot Mirror
There was never an option that allowed you to extract bits from a _real_ PJB. The menu option you are talking about was only used in the PJB's simulator (before real hardware or the communications protocol were developed) -- if you were talking to a "simulated" PJB, the mp3 data was represented as local disk files, and then the Extract Track command would copied the bits out.
The C++ class that implemented the "real" communications protocol had an empty function for that command, since there is no communications protocol support and no firmware support for it to use.
When the simulator was removed, we forgot about the right-button context menu (it still had the option). It pops up a window, asks for a file name, calls the appropriate MFC/C++ function, which contains just one line: "return ERR_NOT_SUPPORTED". There's no code there to implement it. There never was, and there still isn't today. The simulator got all the bugs out, so we never needed to put it in a real PJB.
/Mitch.
That would only work if the PocketPC had a USB _host_ controller on it. Do they? I thought they were peripherals.
The PJB's USB port is a peripheral port (square connector), and you can't connect two peripheral ports together.
Then there's the whole matter of the PJB's file system only being really useful for MP3 data...
/Mitch.
Oversight, I think. It's supposed to be GPL.
Thanks for pointing it out -- I'll try to find out if that message is just boilerplate or not.
/Mitch.
grumble... this issue again.
You have *ALWAYS* been able to just upload the MP3s you have. You don't *HAVE* to use the original CDs, but it sure is convenient if you do have them. (The included Jukebox Manager rips, encodes, and transfers in one step... that's what the documentation is trying to say).
One reason to use the Jukebox Manager is it includes Fraunhofer's best encoder. I re-ripped everything I had when I got my PJB working the first time, but the other encoders have improved in the past few years as well.
If you have a bunch of MP3s, just press the "Add stored tracks" button (4th from the left) and point it at the files to upload.
This SDK is for the part of the code that does that. You wouldn't have had to re-rip your hundreds of CDs ever... not even if you had the first PJB.
Someone _must_ fix that web site it seems!
/Mitch.
Okay, so it's not really the "spirit". What would I know, I'm just a Windows programmer?
Maybe I should ask them to take it away? I think there will be "real programs" eventually, as soon as interested people write them.
/Mitch.
No, Compaq didn't open-source the whole thing. They can't, since there's lots of licensed material in there that Compaq cannot redistribute.
I did much of the work preparing this kit. It was derived from the actual sources, and it includes the key parts you'll need. The rest of it (the stuff that was not included) is Windows MFC stuff. Does anyone here really want that? I thought not
Maybe I shouldn't have said "In the true spirit of open source..." stuff since I'm not even sure I know what that is myself
I'm hoping people will write some interesting applications with this.
/Mitch.
Disclaimer: I speak for me, not Compaq.
Actually, the motivation for releasing this SDK was from requests from customers for Linux support. It wasn't for any recognition, or even money -- customers asked, that's all!
The researchers working on the original PJB prototypes have been working on other projects lately, and writing *another* Jukebox Manager doesn't exactly qualify as research. So, for all those who asked, this SDK is for you.
(I should know, since I helped get this kit released).
/Mitch.
Not being able to retrieve data is a firmware limitation.
/Mitch.
The technology that is in the PJB did not come from Itsy, but both Itsy and the PJB came from Compaq's research labs in Palo Alto, CA.
:-)
Itsy is a StrongARM-based handheld Linux machine. The PJB is a Motorola 56309-based music player. Other than the fact that they're both portable and the engineers frequent the same Palo Alto restaruants, they're quite different
The PJB's technology was licensed to a Korean company called HanGo (dba Remote Solution in the US). They resell the PJB via mp3factorydirect.com, in catalogs via Hy-Tek manufacturing (Hammacher-Schlemmer, etc.). I think there are some other distributors now too.
[I worked on the PJB's firmware - it was a way cool project].
/Mitch.
It looks like it is creating copies of the song, but it's actually just copying directory entries around. You can even rename the copy you made and then make copies of that, and it's _still_ just going to make links.
:-).
The PJB does impose the Set/Disc/Track hierarchy though (something I find mildly annoying but I can live with it). So, all tracks must be in a disc, all discs must be in a set. Usually not a problem though.
Basically, the only way you can eat storage is by ripping CDs or adding MP3s from your hard drive. Everything else is just pointers. One of the many benefits of a custom file system
We should make this clearer in the docs.
/Mitch.
We chose three levels deliberately - four was deemed too complex for non-geeks, two was too flat.
MP3 tag information does lend itself to four levels, though (genre/artist/album/track).
You can define your own sets in the PJB - just create a blank set, create discs in the blank set, and copy the tracks in.
For example, I have a set "Driving Mixes" and discs "Fast Mix" and "Slow Mix". The tracks in these discs come from other things in the Rock set.
Similarly, I have about 90 albums in the Rock set, but I also have a "Beatles" set containing only beatles albums, when I want an all-Beatles day.
The PJB lets you make as many references to music as you want, so a single track can live in multiple discs. The storage is not duplicated.
Doesn't that do what you want?
/Mitch.
That picture _was_ an RJ45 jack. Revision 1 PJBs (the first ones that were actually assembled into portable units) had 10MBit Ethernet controllers on them, since we were familiar with the chip and had lots of them in the lab. About 40 of those were built (I still have mine). Many of the photos you see are of rev1 prototypes, because we were using those pictures to pitch the product viability of the PJB.
:-).
The choice of Ethernet vs. USB was difficult. There are lots of really good reasons to use Ethernet (easy compatibility with all OSes, good performance, even the possibility of using TCP & HTTP to talk to it
But, there are also good reasons to use USB, and that's because many people do NOT have Ethernet controllers, and it's unacceptable to ask them to install one just for this application. Not every customer is a slashdot regular, so we have to cater to less-geeky consumers. USB is also getting lots of press these days.
I don't regret the decision (it was the right move for the product), but I still like the idea of Ethernet myself.
/Mitch.
Your conclusion is not quite right.
"Extract Track" never worked on real PJBs - it was used with "simulated" PJBs eons ago before there was real hardware. It manipulated a container file on the local file system.
Yes, the PJB is just a little computer. Sure, someone could reprogram it to spit data back out. The shipping software doesn't have that support, and there's no code in the Jukebox Manager to deal with it.
That extract track command was removed in 1.5.2. When the simulated PJB support was disabled, we forgot to remove the menu from the resource file.
/Mitch.
[Gack, forgot to do "Plain text" again. Here it is, formatted the way I wanted to see it. Apologies for the double-post.]
"You must make new ones with included software".
No, No, No. Wrong. Incorrect. Where do people get this misinformation?
I worked on the PJB when it was a research project.
It would not be much of an MP3 player if you couldn't put your own MP3s on it. The Jukebox Manager does have its quirks (they are being worked on) that make it difficult to import huge trees of MP3s, but downloading your own MP3s is right there, the fourth button on the toolbar.
BTW, I get about 7X encoding speed on my 450Mhz PII, using Fraunhofer's very fine encoder. I think that's pretty fast, and the quality of the bitstream is excellent.
/Mitch.
"You must make new ones with included software". No, No, No. Wrong. Incorrect. Where do people get this misinformation? I worked on the PJB when it was a research project. It would not be much of an MP3 player if you couldn't put your own MP3s on it. The Jukebox Manager does have its quirks (they are being worked on) that make it difficult to import huge trees of MP3s, but downloading your own MP3s is right there, the fourth button on the toolbar. BTW, I get about 7X encoding speed on my 450Mhz PII, using Fraunhofer's very fine encoder. I think that's pretty fast, and the quality of the bitstream is excellent. /Mitch.
Some minor corrections:
2. Macintosh support is being worked on. I'm waiting for clearance to release an SDK for Linux hackers.
3. The encoding is done on the PC, using Fraunhofer's encoder. The MP3 bits are shipped via USB to the PJB.
4. Not including 160kbps was my mistake. I left it out of the table. We'll get that into a future software update.
6. "menu system feels kind of poorly done." Um, care to explain that? How would you do the menus?
8. The disk will only continuously spin if you're continuously pressing buttons to change songs.
9. [browse while playing] - probably the biggest single requested feature. I think you can count on that eventually getting implemented, as I want it myself, and I worked on the firmware.
/Mitch.
I'll try to post here if/when I finally get to post the SDK. It will include plenty of information (file system documentation, USB protocol, etc.) and an example program that already runs under Linux. I'm very interested in what the Linux world comes up with for a "Jukebox Manager" equivalent application.
There's no firmware support for retrieving data from the PJB, so the SDK won't help with any digital cracking.
/Mitch.
You're right of course, sooner or later more court cases will come out and eventually all this stuff will get straightened out.
:-) want to be the the test case. So, technology-wise I think the PJB has a fair compromise.
I don't think we (a humble research group
That said, (my opinion follows) I can't think of any reasons I'd want to extract music data _from_ my PJB. I've had one for 18 months. What I do _NOT_ want is all the wierd "check-in"/"check-out" stuff that some DRM schemes use, like Sony's MagicGate.
Given a choice, I pick write-only anytime. I really don't want to go down the "rights and freedom" rathole, it's pointless. I just want to carry 100+ of my CDs in a small portable device.
/Mitch.
The only things in common between the Itsy and the PJB is that they're both designed by Compaq Corporate Research, and they're both portable devices. The researchers on both projects eat at the same restaurants... does that count?
The PJB has a 24-bit Motorola 56309 DSP as its CPU, and the Itsy uses a StrongARM SA1100. The PJB doesn't have an operating system at all (real programmers don't need 'em
/Mitch.
The Jukebox Manager lets you encode at 64, 128, 192, 256, and 320kbps. 160kbps was accidentally left out of the table... sigh. Next release maybe.
It uses Fraunhofer's best encoder. It will automatically choose frame-by-frame what stereo mode to use.
It will play back any bitrate (8..320kbps), including VBRs.
/Mitch.
Re: hard drive == corruption possible.
not so.
The file system was specially designed to prevent problems like that. It _never_ writes the disk when you are just playing back, and there is a special database-style "commit" operation when writing data.
Unless there's a bug in the software, the PJB won't corrupt the disk during power failures or other problems.
It's $800 because it costs a lot of money to tool up a factory, order zillions of parts, pay for an injection-molding tool, etc. Hopefully things will improve.
/Mitch.
(who worked on this project when it was a research prototype)
The battery lasts at least ten hours. I never plug mine in unless I'm recharging it or loading MP3s into it.
...
It really is portable - perhaps too heavy for jogging and running, but excellent for walking, driving, sitting at your desk,
/Mitch.
Disclaimer: I worked on this project when it was a research prototype.
I wrote that FAQ. I also wrote a bunch of the firmware in the PJB (here at Compaq Corporate Research). Not wanting to anger the recording industry is why you can't copy files back. Given a choice between that an SDMI, I pick this any day. Nobody's treating anyone like children... we'd just rather make money and let other people have MP3 players than give it to lawyers. As for Linux... let's see. I work in a research lab. Researchers like Linux. The only thing stopping an SDK from being released (under GPL) is legal stuff from the corporation. It takes more than just documenting protocols and stuff (reverse engineering wouldn't yield the best results) - real example programs derived from the real sources are the best way to get a Linux/PJB GPL effort started. Keep your fingers crossed, I'm hopeful we'll be able to get an SDK out soon. /Mitch.