Yet more progress

So today I re-wrote the code used to deal with options so that it looks cleaner and is easier to extend. After doing that I finished support for compressing and decompressing files before/after encoding using zlib. Future plans for compressing include being able to specify what level of compression you want to use.

Fixed many bugs

- Fixed the code for encoding / decoding at 12 bits per sample so it should actually be working properly now.

- Rewrote the code for figuring out the number of bits that we should encode / decode per sample. This should fix any problems associated with getMinBitsEncodedPS().

- Changed how we calculated to data buffer size to avoid certain issues.

Progress

The code rewrite is now well underway, thanks to tom, and the new system is much cleaner and uses better formulas. There is still a bug in the system for dealing with 8 bit wav files.

I have also started putting together compression support using zlib version 1.2.4. The code is in the repository and compiles on its own, but has not been tested or incorporated into the program as of yet.

bug discovered.

In the process of adding better 24-bit wav support and 32-bit wav support, I ran across a fairly large bug in our code that determines if the specified data file can fit in the wav file and how many bits should be used in the process. Tom and I talked and we have decided to change plans to fix this bug the right way by rewriting that part of the code. Until we finish fixing it, we won't be making many changes to improve wav file support.

Bug Fixes

We tested buffering a little more, but the most recent commits have all been fixing a comparability issue between 32 and 64 bit machines. There has also been a slight change of plan. We have decided that it would be in our best interest to write a program that tests the basic functionality of our program without us having to manually enter all the files and check them ourselves. This will be a more back-burner project, but it's development will most likely start shortly.

Buffering Complete

File buffering has been implemented in Awesome-WAV. The program will no longer use huge chunks of memory when manipulating WAV files and will no longer make excessive I/O calls when encoding / decoding data files.

We will continue making changes and optimizations to how we handle buffering until we are satisfied.

We have not yet tested all file combinations so the program may fail in some cases.

RCOS Introduction

Last Friday Tim and I gave our first RCOS presentation. We gave a brief introduction about Awesome-WAV; the slides can be found here.

Very busy

Tim and I have been very busy these past couple of weeks and as a result we haven't made as much headway as we would have liked. Luckily next week is spring break so expect more progress soon.

More recent update

Well it appears that the code is now reachable from the RCOS dashboard.

Progress is steady on adding buffering to the project. We came to an agreement about how to implement it, and now there are only a few changes left before it is implemented for encoding.

Buffering...

At the moment Awesome-WAV loads entire .wav files into memory before messing with the data.  Since PCM WAV files can easily reach 50MB+ in size we have decided that we must implement some sort of file buffering for encoding / decoding data.  We could just fread each individual byte, but that would add considerable overhead.  Instead we will read / modify / save several large chunks of data at a time (1MB blocks maybe?).  Right now we are just making structural changes to the code to make implementing buffering easier.