Preston Lacey

I just posted an update that should fix these two bugs.

I've been looking at that section of code and I think I found the bug. There's an unchecked access on a potentially null object in the method samplesAvailableToEncode(). If it happens that the number of samples added up to the point you call samplesAvailableToEncode() is a perfect multiple of the block-size used by the encoder, it should trigger the exception(or if no samples were ever added). I'll create a test case and verify this later tonight. Hopefully I will get the update posted tomorrow to...

I haven't seen that before but it sounds like an internal bug in the flac library. I'll check it out. In the meantime, can you tell me the conditions of the failure(which javaFlacEncoder version, encode settings used, is this still 16-bit mono as above?)

Interesting. The header for the #277 file is properly finalized, while the header for #388 is not. Does your code only occasionaly fail to produce a proper file now, or always fail? For example, did the run that verified the two values were equal also produce a good file, or a bad file? My point is I'm curious if something is only occasionally interrupting that code before it reaches the point of finalizing the header. I did check the library source though, and there is indeed a bug that might cause...

I'm not actually certain at the moment what might be the problem. It sounds like the FLAC stream is not being finalized by the line, "flacEncoder.encodeSamples(flacEncoder.samplesAvailableToEncode(), true)" When the flac stream is finalized, various details needed for seeking(including length of stream and min/max encoded frame size) are written to the front of the stream if possible(this step will be ignored if the stream isn't seekable, but yours should be since you're writing to a file). First...

Unfortunately, there's not a built-in way to properly append new data directly to a previously saved file using this encoder. Information about the encoded data(md5-hash, length, number of frames, etc) is kept while encoding, and this information is written out to the header space of the FLAC stream when the stream is closed. Currently, there is no method of restoring the encoder state necessary to write a proper header to the existing stream if appending new data.

Greetings! I can't be certain without more information on your source format and how you're reading them from the AudioRecord instance, but It looks like your problem will be with the source format conversion to int. If you're reading 16-bit PCM from the AudioRecord object, make sure you're reading those into a short[] and not a byte[] https://developer.android.com/reference/android/media/AudioRecord.html#read(short[],%20int,%20int) If you use a byte[] for 16-bit(which is deprecated but should work),...

Excellent, glad to hear it's working for you. You should be able to do the conversion...