View Full Version : zip and tar reading?

2006-04-24, 08:46
Excuse me if I seem lazy or ignint but I haven't seen anything about this, so far.

Does slimserver 6.2 read straight from zip, gzip, tar, etc. files?

My favorite local player, Foobar2000 has a module which does so. It's very handy. Although most of my library is not zipped it would be great to have this capability for at least 3 reasons I can think of right now:

1. would save even more storage space.

2. easier to transfer entire artist directories.

3. I won't have to unzip all the files I have already zipped.

If slimserver doesn't then maybe there's a plugin? Or maybe the module from FB2k can be adapted...? or...?

Any response appreciated.


Mark Lanctot
2006-04-24, 08:59
Does it really lead to any space savings though?

I thought I had read somewhere that most audio files are so compressed that zipping them does not result in any appreciable space savings. So I tried a test.

First, an 18.3 MB FLAC file. Using 7-Zip on the "Ultra" setting, it took a fairly long time to zip it to...an 18.3 MB ZIP file. No space savings.

On a 2364 KB MP3, this resulted in a 2299 KB ZIP. That's a 2.8% reduction.

It could be nice, but is it really worth the effort? Is space so much at a premium?

Don't want to shoot down your idea but I don't see how much space you'd really save. If you have different results I'd like to hear. I guess if you have it saved as WAV files this would work, but just encode to FLAC in that case.

2006-04-24, 09:03
1. would save even more storage space.

on this point, I don't think so. Take a look what the size of a directory full of mp3s are, then zip 'em up and look at the size of the zip. I don't think you're going to save squat in disk space...mp3s aren't going to compress any further than they already are.

As a test, I zipped up an album and compared raw files to the zip. They are the same...
bklaas@mediumspicy /tmp $ du -h Calexico\ -\ Hot\ Rail/
106M Calexico - Hot Rail/
bklaas@mediumspicy /tmp $ ls -lh c.zip
-rw-r--r-- 1 bklaas wheel 105M Apr 24 10:59 c.zip
bklaas@mediumspicy /tmp $

Your point #2 has some merit, but I don't think there's any space savings in #1.

FWIW, I know of no slimserver function to unzip on the fly.


2006-04-24, 09:14
1. would save even more storage space.

2. easier to transfer entire artist directories.

3. I won't have to unzip all the files I have already zipped.

1. As Mark & Ben have already pointed out, most audio formats are already compressed, so compression utilities like zip, gzip, etc. won't squeeze any more space out of them. But unzipping them will chew up processor time. And I suppose that zip/gzip would end up taking *more* space, at least in the short run, because you'd have to have some free space to put the unzipped file, while keeping the zipped version at least until the unzipping is finished.

2. Seems to me you can get this pretty easily already if you move/copy from the right place in the directory tree. All OSs should handle this easily, whether command line or GUI.

3. Actually, you'd be unzipping the files every time you played them, rather than just once. It would just be less visible.

I'm a big fan of zip and gzip, but I don't see the gains in this particular application.

2006-04-25, 00:58
2. easier to transfer entire artist directories.


If you are using Windows and want to do this for backup then use robocopy from the Windows Server 2003 toolkit. Runs fine on XP and can give you an identical folder copy.

2006-04-27, 18:52
Somehow my subscription to this thread did not register so a nice surprise to see all these responses.

I mis-prioritized my reasons, I guess, just rattling them off the top of my head.

But still nice to corroborate what I kind of expected as far as the space savings. Foobar does not actually encode on the fly so it does a great job with playing right out of the zips. And since it does this so well I was assuming that it was fairly easy to do. I see that this is not desirable for streaming.

My initial ideal was to avoid encoding on the fly as much as possible even considering the network cost. I want it to sound as good as possible. So I thought the unzipping could use the time left that encoding would take.

Let me list as a new #1 reason:
I'm pushing these systems to friends and relatives who are not so tech-ie and I'm trying to keep the user interface as simple as possible.

I really appreciate the hint about Robocopy! and I will def check it out.