Rockbox Technical Forums
Rockbox Development => Feature Ideas => Topic started by: solrize on September 13, 2008, 10:57:00 PM
-
Lots of times, albums are distributed as zip archives containing a number of flac, ogg, or mp3 files. It's a nuisance to have to unpack them to a player into a directory full of files for individual tracks. It would be great to be able to just copy the .zip file to the player, and have rockbox treat the zip as if it were a folder, supporting normal playback and (preferably) navigation functions. If it's not possible to add or delete entries to a zip, that is ok; main thing is to be able to play files that are inside the zip.
-
A couple of thoughts:
This would likely be very slow. The processors in the majority of our targets are not speedy.
Furthermore, having an unzip routine in the core (as would be needed for this) would add quite a bit of code for not (IMO) a huge benefit - if you have to copy a zip file onto the player why not just uncompress it at the same time? You could write an unzip plugin if you are willing to put up with the time and battery it would take to use it.
-
1. I don't think it would be slow or add much code, at least for deflate. The zlib uncompression routine is very simple and fast. Compression is much slower but that's not what's used here. I think all current dap's that are sensible rockbox targets have cpu's that are more than fast enough. Remember that zip format goes back to the pc-xt era (4.77 mhz 16 bit cpu) so by that standard, today's ARM processors are practically supercomputers.
2. Of course unpacking the zip when I put it on the player is what I do now. It's just that these zips are so common that it would be a significant convenience win to be able to just drop them onto the player without unpacking.
3. The idea of a plugin is interesting, I'll have to look at it further. Thanks.
-
1. I don't think it would be slow or add much code, at least for deflate.
Playing mp3 files contained in a zip with foobar2000 makes it noticably slower, at least for me.
I think all current dap's that are sensible rockbox targets have cpu's that are more than fast enough. Remember that zip format goes back to the pc-xt era (4.77 mhz 16 bit cpu) so by that standard, today's ARM processors are practically supercomputers.
back those times you didn't compress 50+ MiB into an archive. Also, keep in mind that the format itself has moved to support better compression. Last, you also need to play the extracted content the same time.
It's just that these zips are so common that it would be a significant convenience win to be able to just drop them onto the player without unpacking.
I don't have any on my player, and I don't think they are common -- if I encode CDs I see no point in putting the resulting files into an archive, and music bought on itunes and the like also doesn't come in a zip file. Besides, if you have such a zip file, I bet this has some kind of compression enabled. Supporting deflate only would most likely work on a minority of those "common" files, if not even less. Which would make this additional convenience for you somewhat pointless.
Also, IMO this would only add unnecessary complexity for almost no gain.
-
I keep a lot of text files and tracker-format songs in ZIPs, and this usually saves a pretty good deal of space (especially because the smaller files are no longer hogging a 64KB cluster when they're ~10KB, and the like on FAT). Most of these archives would not be very large. Though I agree that it probably wouldn't justify adding ZIP support to the core of the firmware, I'd still love to see a plugin. The user could "launch" a ZIP file and just see a list of contents, then choose a file to extract.
Also, slow unzips do not bother me. On my Palm with a program called UniCMD, it takes a full minute to unzip a file that, unzipped, is a megabyte in size. Yet I do it all the time, even though my desktop could do the job in a second. The reason? I have time, but I do not have money (to buy bigger memory cards).
(Yes, I am a college kid. No, it is impossible for me to get a job right now. My relatives will not let me use their cars.)
-
It's completely understandable that neither of us has zips on our players right now, since the players don't know how to decode the zips. If the players could decode zips, I'd be using them, and maybe you'd be too!
For example, Magnatune.com and jamendo.com both distribute their cd downloads as zips containing mp3/flac/ogg files. Archive.org also has a tremendous number of zips, see for example
http://www.archive.org/details/gd1975-06-17.aud.unknown.87560.flac16
although you can download those as separate files, getting the zip is more convenient.
I don't know why foobar is slower when you play from a zip. There's not a good reason for it to be slower that I can figure out.
Obviously the most sensible way to store these compressed audio files in a zip is with no compression (just use the 'store' format), but in reality people tend to make these zips using the default zip options, which attempt compression. In fact deflate can often compress an mp3 by a tiny amount (like 1 or 2 percent) but at worst there's a tiny expansion (no compression, plus some deflate headers get added).
The cpu requirements of uncompressing zip is a lot smaller than for decoding mp3 or ogg. Running decompression and playback simultaneously really truly isn't a problem for most of today's players (which for the most part have cpu's fast enough to run video codecs). See http://www.rockbox.org/twiki/bin/view/Main/CodecPerformanceComparison for some timings that indicate the amount of cpu left over after various codecs are run (i.e. one that runs 300% real time leaves 2/3 of the cycles available).
I suspect strife98's slow Palm unzipping is due to file i/o slowness rather than because of the unzip algorithm itself.
-
Feel free to code it, but I don't think this'll make it into Rockbox even if someone does.
It adds code size and complexity for very marginal gain.
-
Feel free to code it, but I don't think this'll make it into Rockbox even if someone does.
It adds code size and complexity for very marginal gain.
I think the gain would not be marginal; the more I think about it, the more I realize that almost all of my music downloads are zips, though I'm maybe non-typical in that I don't use itunes and I don't rip cd's that often. However, I agree that a plug-in sounds like the right way to go, if it can be presented in the user interface nicely. I don't know the software well enough to have a sense of that right now.
-
Adding Zip support would be extremely difficult, since the audio buffer is expected to contain raw file data. You'd either have to write a special codec for mp3 in zip, ogg in zip, etc or else try and change the file buffer functions to intercept zipped data and somehow convert it on the fly.
-
Intercepting the file coming in and unzipping it on the fly sounds like the right approach. I'm surprised if there's nothing like it already. It would be needed to handle nested ogg containers and that sort of thing.
-
Intercepting the file coming in and unzipping it on the fly sounds like the right approach. I'm surprised if there's nothing like it already.
As I said, its difficult to implement, so its not surprising that no one has done it. As things become more difficult, the odds of them being done decreases rapidly . . .
-
I suspect strife98's slow Palm unzipping is due to file i/o slowness rather than because of the unzip algorithm itself.
Indeed, I knew about that, but failed to point it out; though unzipping is still slower than copying a non-compressed file (and not just because it unzips to RAM and then copies).
My Palm takes ~20 seconds to copy 5 MB from RAM to the card. The same file, with the same card, with a good card reader, takes 3 or 4 seconds on my PC.
Though I agree that it probably wouldn't justify adding ZIP support to the core of the firmware, I'd still love to see a plugin. The user could "launch" a ZIP file and just see a list of contents, then choose a file to extract.
I feel as though noone even thought about my suggestion. I probably should add that a file could be copied from the ZIP file to its uncompressed self elsewhere on the storage media, instead of trying to route it directly to the appropriate player/ plugin.
-
My Palm takes ~20 seconds to copy 5 MB from RAM to the card. The same file, with the same card, with a good card reader, takes 3 or 4 seconds on my PC.
You can't tell anything about unzip speed, by comparing a transfer through the Palm against a transfer through a card reader. Try the following:
Put the 1MB unzipped file on the card, into the Palm. On the palm, copy the unzipped file to another file, and see how long it takes. Then put the zipped version on the card, put the card into the Palm, and time how long it takes the Palm to unzip the file to another file.
-
I think the gain would not be marginal; the more I think about it, the more I realize that almost all of my music downloads are zips, though I'm maybe non-typical in that I don't use itunes and I don't rip cd's that often.
In my opinion, the gain is still very marginal. The vast majority of users do just fine without ZIP files.
Besides, there's a very easy workaround: unpack the ZIP files to separate folders on the player.
-
I keep a lot of text files and tracker-format songs in a few ZIPs, and this usually saves a pretty good deal of space (especially because the smaller files are no longer hogging a 64KB cluster when they're ~10KB, and the like on FAT). ... Though I agree that it probably wouldn't justify adding ZIP support to the core of the firmware, I'd still love to see a plugin.
-
As I said, its difficult to implement, so its not surprising that no one has done it. As things become more difficult, the odds of them being done decreases rapidly . . .
.....Increases rapidly :-X
This unzip tool would be nice as a plug-in application. Is 7z fully open source? I'm betting it's processor heavy anyway
-
7-Zip actually isn't that bad on a 10-year-old computer I have. And said computer has a 166MHz processor. :D
-
7-Zip actually isn't that bad on a 10-year-old computer I have. And said computer has a 166MHz processor. :D
So would it be feasible on a player do you think?
-
i would also very much like to see support for zip files as well as encrypted zip files.
-
I'd like to see Rockbox have built-in support for making coffee.
-
I'd like to see Rockbox have built-in support for making coffee.
Hear hear. Open source coffee. Java beans are the most processor efficient I believe. Kopi Jawa