Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: problems arising from zipped files  (Read 1572 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

problems arising from zipped files

hi everyone =]

after discovering that foobar2k had the ability to play from .zip files, i recently converted almost my entire library [just a little under three-and-a-half-weeks' worth !] from uncompressed folders to zipped folders [to clarify: multiple zipped folders, not one monolithic monstrousity]. after a number of shenanigans, things are going great!

it's a little slow to read, but to me that's an acceptable loss for more than halving the amount of space i was using before [previously, i was maintaining a seperate "archive" folder with all the albums zipped up; now, my library and that "archive" are one and the same]. however, in the process i found a number of rather irritating curiosities on the way, which i shall detail here.

first of all, the most pressing issue: when scanning the library, there seems to be some sort of memory leak - the RAM used by foobar2k slowly rises up by an order of magnitude, dwarfing everything else i normally run - even chrome, of all things [!] - and eventually maxes out all the RAM i have, leaving my computer nearly completely unresponsive from the pagefile thrashing until it finishes the scan.

fortunately, i solved this by disabling the option to scan the library at startup, though this leaves me in the rather undesirable position of having to manually re-scan every time i wish to add to my collection, which as a fan of indie music i do fairly frequently. it seems that after completing the scan memory usage returns to reasonable levels, but the scan does take quite some time to complete - ideally, i would be able to leave it scanning in the background as per the default settings without needing to put my work on hold in order to allow it to do so.

now, the second problem i've been facing, which is really two rolled into one: foobar is unable to write tags to files within zipped folders, and similarly cannot "open containing folder" - this last issue is understandable, since it could be said that the containing folder does not strictly exist; rather, the zipped folder is itself one continuous file - but it would be nice if upon clicking this option foobar2k instead opened the folder containing the .zip file.

being unable to rewrite the tags of zipped files is generally less inconvenient for me as i seldom need to, though it would be greatly appreciated - for example, one artist i follow recently came out as transgender, and out of respect for her new identity and not wanting to cause her to run out of bandwidth [from re-downloading her work] i would like to re-tag the relevent fields from within foobar - otherwise, i would have to extract the files, edit them in this state, and then repackage them before finally re-running the library scan - obviously not something i am keen on in this state =]

thank you for taking the time to look at these issues.
yours,
Su

Re: problems arising from zipped files

Reply #1
The stock archive component, and my archive components, generally unpack files to memory the whole time they're open.

Re: problems arising from zipped files

Reply #2
I consider the archive support more of a convenience feature for quickly testing downloads and not something for permanent use. You already saw how demanding dealing with arhives is. It slows file opening down as everything has to be extracted. This consumes either memory if done to RAM or slows things further down with large archives when extracted to temporary directory on the hard drive. It makes the files read-only from foobar2000's perspective as any editing would require recompressing the archives and there is no support for that.

What kind of file format(s) are you dealing with to benefit so greatly from zipping? If they are something you could compress with regular lossless compressors like FLAC, WavPack and TAK you definitely should use those. They compress better than ZIP and cause no side effects.

If they are some tracker type music you could test the NTFS directory compression in Windows. It won't compress as well as zip but it won't cause noticeable performance problems.

Re: problems arising from zipped files

Reply #3
What kind of file format(s) are you dealing with to benefit so greatly from zipping? If they are something you could compress with regular lossless compressors like FLAC, WavPack and TAK you definitely should use those. They compress better than ZIP and cause no side effects.
hmm, i thought i mentioned it in my original post, but i see i must have forgotten; it's mostly Flac and Ogg, with a number of Mp3s i can't get in higher quality and the very occasional trackers and VGM. the real reason it's such a drastic change, though, is this:
previously, i was maintaining a separate "archive" folder with all the albums zipped up; now, my library and that "archive" are one and the same].
i get most of my music from bandcamp, which serves zipped folders; i was hoping foobar2k's ability to read archived files would allow me to skip the extraction step and also let my loss-averse brain have its "archive" without actually doubling the space used. alas, it seems i shall just have to train it to accept an unzipped music "archive". =]

If they are some tracker type music you could test the NTFS directory compression in Windows. It won't compress as well as zip but it won't cause noticeable performance problems.
oh, oh? i've not heard of this feature before, i'll have to look that up. thank you!

Re: problems arising from zipped files

Reply #4
i get most of my music from bandcamp, which serves zipped folders; i was hoping foobar2k's ability to read archived files would allow me to skip the extraction step and also let my loss-averse brain have its "archive" without actually doubling the space used.

You should keep your Bandcamp purchases, since Bandcamp might very well cancel your purchases after you have paid:
https://hydrogenaud.io/index.php/topic,108139.msg959843.html#msg959843

But, you should never run your collection without backup anyway! Use a separate drive. If you want to have your Bandcamp purchases in the original .zip folders, then keep them on that one. An off-site backup is a good thing too.

I understand that saving little bits of space is not your objective, your idea was not having to spend extra space on .zip (dropping backup, bad idea!).  So NTFS compression gives you hardly anything to write about for music.

(Well, except for files with excessive padding, and if they are lossless, then you can just recompress them using FLAC anyway. Explanation: there is an "empty space" between tags - including pictures - and music, so that one does not have to write the entire file every time tags are updated. If a picture is removed, the space is not reclaimed.)