Fix sample count in ALAC encoded files ?

[Miesepies]

In the 14.2 release one of the fixes is one for the ALAC encoder:


Bug Fix: ALAC encoder writing correct internal sample count

This problem is most likely why so now and then songs seem to end a bit too early.

Can I fix the sample count from the previously converted songs with the new version ? Do I need to reconvert ? I have ~5000 ALAC encoded songs which I want to repair...

[timw0932]

I never noticed songs ending early, but I would always do the following anyway for good measure because I didn't like seeing "minor discrepancies" in foobar2000's verifier for my converted ALAC files, and because, well, you never know. You would start on (2):

1. Convert to ALAC if necessary; these will be the "source files".
2. Open iTunes by Shift+Clicking its pinned icon on the Windows 7 superbar.
3. Have iTunes create a new, temporary library on a different drive than contains the source ALAC files. (This is to make the conversion faster and easily distinguish the new from old files. Make sure you don't locate it in your real iTunes library!)
4. Drag the source files into the new iTunes library.
5. Select all the files in iTunes, right-click any one of them, and select "Create Apple Lossless version" from the context menu that appears. (The conversion file type option depends on how you configured the iTunes "Import Setting" in Preferences. Yes, we want to convert ALAC to ALAC.)
6. After iTunes finishes, use Mp3tag to rename the new ALAC files to their final locations.
7. Exit iTunes and open it again as in (2) but open the "real" iTunes library instead of creating a temporary one.
8. Drag the new, fixed ALAC files into the real iTunes library. These files pass the foobar2000 verifier.
9. Delete the temporary iTunes library and the source files.

Note that the foobar2000 binary comparator, which compares only the decoded data, always found the original FLAC files, the "bad" ALAC files with the wrong lengths, and the "good" ALAC files created by iTunes to be identical. It was only its verifier that noticed the length/sample (non) issue.

I expect you can do the same (convert ALAC to ALAC to fix the errors) with dbpa 14.2, but I haven't tried it. I can say that the FLAC files it converts to ALAC pass the foobar2000 verifier and binary comparator with flying colors, so I no longer need to do any of this rigmarole when going FLAC->ALAC.

[dbfan]

Converting alac to alac fixes any issues

[Miesepies]

I never noticed songs ending early

My iPod cuts of songs a second early... in a lot of tracks its not an issue (due to fade out for example) but for some its very noticable.


Converting alac to alac fixes any issues

I did a small run of about 100 songs, ALAC to ALAC. All the files where roughly 2kb larger than the original. How is that possible ?

[Spoon]

The audio data will not have changed, rather tag padding, in Codec Central you can find in the Utility section 'Calculate Audio CRC' convert an old + new file to this pretend codec and it shows the CRC of the audio.

[Stuart7]

Is it worth worrying about this? I have checked using foobar and the effect is usually fractions of a second. Are the songs actually going to be playing a fraction of a second out?

[Spoon]

FB decodes the old files 100% correctly. It is just a technical blip.