Apple

$ afinfo ref_pink.wav

File: ref_pink.wav

File type ID: WAVE

Data format: 1 ch, 44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer

no channel layout.

estimated duration: 5.000 sec

audio bytes: 441000

audio packets: 220500

bit rate: 705600 bits per second

packet size upper bound: 2

audio data file offset: 44

optimized

----

I convert it to alac with afconvert:

$ afconvert ref_pink.wav -f m4af -d alac ref_pink.m4a

$ afinfo !$

File: ref_pink.m4a

File type ID: m4af

Data format: 1 ch, 44100 Hz, 'alac' (0x00000001) from 16-bit source, 4096 frames/packet

Channel layout: Mono

estimated duration: 4.984 sec

audio bytes: 340642

audio packets: 54

audio 219816 valid frames + 0 priming + 684 remainder = 220500

bit rate: 543341 bits per second

packet size upper bound: 6478

audio data file offset: 4096

optimized

----

And then back to wave:

$ afconvert ref_pink.m4a -f WAVE -d LEI16 out.wav

$ afinfo !$

File: out.wav

File type ID: WAVE

Data format: 1 ch, 44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer

no channel layout.

estimated duration: 4.984 sec

audio bytes: 439632

audio packets: 219816

bit rate: 705600 bits per second

packet size upper bound: 2

audio data file offset: 4096

optimized

----

As you can see according to afinfo I went from 220500 packets in the original to 219816 packets, a loss of 684 (which probably not coincidentally equals the alac remainder). I verified that the new wave had indeed lost 684 frames from the end.

To investigate further, I opened the original wave using ExtAudioFile. It reported that kExtAudioFileProperty_FileLengthFrames was 220500, as expected. I opened the alac file, and the result was 219816. The new wave also had 219816 frames, for a loss of 684.

For grins, I converted the same wave to a .caf (alac) file:

$ afconvert ref_pink.wav -f caff -d alac ref_pink.caf

$ afinfo !$

File: ref_pink.caf

File type ID: caff

Data format: 1 ch, 44100 Hz, 'alac' (0x00000001) from 16-bit source, 4096 frames/packet

no channel layout.

estimated duration: 5.000 sec

audio bytes: 340642

audio packets: 54

audio 220500 valid frames + 0 priming + 684 remainder = 221184

bit rate: 543341 bits per second

packet size upper bound: 6478

audio data file offset: 4096

optimized

sound check:

approximate duration in seconds 5

----

And as a final sanity check I converted the wave to alac using iTunes:

$ afinfo ref_pink-iTunes.m4a

File: ref_pink-iTunes.m4a

File type ID: m4af

Data format: 1 ch, 44100 Hz, 'alac' (0x00000001) from 16-bit source, 4096 frames/packet

Channel layout: Mono

estimated duration: 5.016 sec

audio bytes: 340642

audio packets: 54

bit rate: 543341 bits per second

packet size upper bound: 6478

audio data file offset: 4110

optimized

sound check:

sc ave perceived power coeff 374

sc max perceived power coeff 0

sc peak amplitude msec 4039

sc max perceived power msec 555

sc peak amplitude 0

----

and then back to wave using afconvert:

afconvert ref_pink-iTunes.m4a -f WAVE -d LEI16 ref_pink-iTunes.wav

$ afinfo !$

afinfo ref_pink-iTunes.wav

File: ref_pink-iTunes.wav

File type ID: WAVE

Data format: 1 ch, 44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer

no channel layout.

estimated duration: 5.000 sec

audio bytes: 441000

audio packets: 220500

bit rate: 705600 bits per second

packet size upper bound: 2

audio data file offset: 4096

optimized

----

The strange thing is that when I open the the intermediate alac files in Audacity, they show up with the correct (220500) frame count, in spite of what is reported by afinfo. It is only when converted back to wave that the data is actually lost.

I can also open the alac files in iTunes, and when converted to wave I get the original wav back with no loss.

Does ExtAudioFile handle the magic cookies automatically? Could this be the source of the problem?

Stephen