Zip / Uncompress Questions

Other
#1

Hi.

I am making a game that has 32 level bgm MP3 files. I put them all in a zip file in the main directory to save file size. When the game starts they get uncompressed and sent to a folder ‘bgm’ in the system.CachesDirectory. If the ‘bgm’ directory already exists when the zip is ready to uncompress, then it gets deleted before the uncompress creates a new fresh version of the folder.

My questions are:

  1. Is the Caches Directory the correct and proper place to store unzipped files / audio? I read in the documentation or a thread on zip that iOS required zip files to go into the CachesDirectory. I shouldn’t unzip them to ResourceDirectory or any other path, right?
  2. The documentation for the cachesDirectory said that files kept there are not synched for iOS. Is this still true? What about for android? Do I still need to set the sync for all files extracted to this folder?

I want to make sure that I’m not accidentally backing up numerous megabytes worth of data with icloud.

#2

I personally use the temporary folder for this, but in your case that would require you to unzip the files on the next app cold-start or at least to see if they got deleted between sessions.

Note: You said you read some thread(s) and or doc(s).  Please link them so we can also refer to them when answering you.

#3

I believe on Android, system.CachesDirectory and system.TemporaryDirectory are the same location, or maybe we create a caches folder inside of system.TemporaryDirectory. On iOS the rules for when the system purges data is different. system.TemporaryDirectory will likely get purged before system.CachesDirectory.

Only system.DocumentsDirectory gets backed up to iCloud or the Google Equivalent.

Rob 

#4

@roaminggamer

(claims that chachedDirectory doesn’t get synced.)

https://docs.coronalabs.com/api/library/system/CachesDirectory.html

(recommends that uncompressed zip files should go in chachesDirectory)

(I don’t know if this is the original thread I saw, but this was the closest I could find.)

https://forums.coronalabs.com/topic/35306-storing-additional-game-content-where-can-we/

Thank you @roaminggamer and @Rob Miracle for responding!

#5

Did I miss something fundamental here?

It usually makes absolutely no sense to put mp3 files into a zip as mp3 is already highly compressed. So if you put 32 mp3 files into a zip within your project and in addition extract the files into a temporary/cache folder, you not only do not save anything but instead waste storage for now reason.

#6

Michael, it’s quite true that Zip compression won’t save much, if any space with MP3 files, however, it can save code time. I know this isn’t the case here, but if you have 50 .MP3 files to download from a server, it’s going to be better to download a single .zip file and unzip it rather than making 50 HTTP requests and have to process 50 different event handlers.

Christopher, Michael brings up a really good point. I’m not sure you need to be doing this. You’re not saving any space, in fact, you end up doubling the storage for the .MP3 files. It takes time to unzip them before you can start loading them and there is no guarantee that they will stay in the Caches or Temporary folder meaning you may have to unzip them again.

Now if you want to save space in your initial download, you can use this technique to download the audio from a server, but if you’re keeping the files in your app bundle, you’re not saving anything.

Rob

#7

@Rob Miracle

’

I see what you mean. I just wanted to make the music as small as possible when submitting the app since the limit is 100mb.

My music files, which includes 32 songs between 30 second and 1 minute, plus numerous short fanfare jingles, take up 48mb when uncompressed. They are 320kbps which is high, but when I tested them at 128kbps and lower, the saving was minimal, shaving off only a couple hundred kb off the file size of each file. changing sample quality and other settings in FL Studio didn’t make a dent either. i was concerned about what would happen in a future project if I needed 30+ tracks that were longer than 1 minute each.

I decided to zip the music because Google and Apple’s app file size limits are 100mb. When the files are zipped up, they only take up 22mb compared to the original 48. My main goal was that the app pass submission size requirements.

If you think I’m better off just putting the music in a folder in resources, then I will. I don’t think that keeping the music zip on a server is a practical option for me.

#8

That’s a pretty extreme difference and it sounds like there’s something wrong with the initial compression of your files - especially given you don’t see any benefit by reducing from 320kbit to 128kbit, which is the definition of how much bits per seconds are used to encode the file (fixed bitrate or at least around that number if its vbr encoded).

7z f.i. doesn’t even try to compress mp3 when put into a zip by default … it simply switches to storage mode (7z format manages to compress mp3 files a bit, but not even close to 50%)

#9

@Michael Flad

Last night I went into FL Studio and tried messing with the export settings. I disabled all quality and data options in addition to reducing the bit-rate. I tested 320kbps vs 128kbps on a 30 second song. The difference was 1mb getting cut down to 500 something mb. So about half. This helps the immediate problem.

I guess I’m satisfied for now. I’m going to return the music files to the resources directory and try reducing the bitrate. Thank you everyone for your feedback.

#10

I personally use the temporary folder for this, but in your case that would require you to unzip the files on the next app cold-start or at least to see if they got deleted between sessions.

Note: You said you read some thread(s) and or doc(s).  Please link them so we can also refer to them when answering you.

#11

I believe on Android, system.CachesDirectory and system.TemporaryDirectory are the same location, or maybe we create a caches folder inside of system.TemporaryDirectory. On iOS the rules for when the system purges data is different. system.TemporaryDirectory will likely get purged before system.CachesDirectory.

Only system.DocumentsDirectory gets backed up to iCloud or the Google Equivalent.

Rob 

#12

@roaminggamer

(claims that chachedDirectory doesn’t get synced.)

https://docs.coronalabs.com/api/library/system/CachesDirectory.html

(recommends that uncompressed zip files should go in chachesDirectory)

(I don’t know if this is the original thread I saw, but this was the closest I could find.)

https://forums.coronalabs.com/topic/35306-storing-additional-game-content-where-can-we/

Thank you @roaminggamer and @Rob Miracle for responding!

#13

Did I miss something fundamental here?

It usually makes absolutely no sense to put mp3 files into a zip as mp3 is already highly compressed. So if you put 32 mp3 files into a zip within your project and in addition extract the files into a temporary/cache folder, you not only do not save anything but instead waste storage for now reason.

#14

Michael, it’s quite true that Zip compression won’t save much, if any space with MP3 files, however, it can save code time. I know this isn’t the case here, but if you have 50 .MP3 files to download from a server, it’s going to be better to download a single .zip file and unzip it rather than making 50 HTTP requests and have to process 50 different event handlers.

Christopher, Michael brings up a really good point. I’m not sure you need to be doing this. You’re not saving any space, in fact, you end up doubling the storage for the .MP3 files. It takes time to unzip them before you can start loading them and there is no guarantee that they will stay in the Caches or Temporary folder meaning you may have to unzip them again.

Now if you want to save space in your initial download, you can use this technique to download the audio from a server, but if you’re keeping the files in your app bundle, you’re not saving anything.

Rob

#15

@Rob Miracle

’

I see what you mean. I just wanted to make the music as small as possible when submitting the app since the limit is 100mb.

My music files, which includes 32 songs between 30 second and 1 minute, plus numerous short fanfare jingles, take up 48mb when uncompressed. They are 320kbps which is high, but when I tested them at 128kbps and lower, the saving was minimal, shaving off only a couple hundred kb off the file size of each file. changing sample quality and other settings in FL Studio didn’t make a dent either. i was concerned about what would happen in a future project if I needed 30+ tracks that were longer than 1 minute each.

I decided to zip the music because Google and Apple’s app file size limits are 100mb. When the files are zipped up, they only take up 22mb compared to the original 48. My main goal was that the app pass submission size requirements.

If you think I’m better off just putting the music in a folder in resources, then I will. I don’t think that keeping the music zip on a server is a practical option for me.

#16

That’s a pretty extreme difference and it sounds like there’s something wrong with the initial compression of your files - especially given you don’t see any benefit by reducing from 320kbit to 128kbit, which is the definition of how much bits per seconds are used to encode the file (fixed bitrate or at least around that number if its vbr encoded).

7z f.i. doesn’t even try to compress mp3 when put into a zip by default … it simply switches to storage mode (7z format manages to compress mp3 files a bit, but not even close to 50%)

#17

@Michael Flad

Last night I went into FL Studio and tried messing with the export settings. I disabled all quality and data options in addition to reducing the bit-rate. I tested 320kbps vs 128kbps on a 30 second song. The difference was 1mb getting cut down to 500 something mb. So about half. This helps the immediate problem.

I guess I’m satisfied for now. I’m going to return the music files to the resources directory and try reducing the bitrate. Thank you everyone for your feedback.