Bugzilla – Bug 238
AIF importer ignores 'offset to start of sound samples' in SSND chunk
Last modified: 2018-08-20 11:53:59 UTC
The file served up by the Finder when importing a CD track is actually an AIFC/sowt file, and has a non-zero offset in the SSND chunk. iTunes correctly identifies this offset and does not include the 570 samples at the start of the SSND data. Audacity correctly identifies the reversed byte order of the AIFC/sowt file but ignores the 'offset to start of sound samples'.
My current feeling in the absence of any comments from a Mac developer to the contrary is that this is at best a P4 (so currently rated as such). Only a minority of AIFFs have non-zero offsets, even though CD importing may be a common activity. Also in most cases the effect will be inaudible (I gather it is perceptible if importing what should be a "gapless CD")? Does this occur only when importing with libsndfile i.e. when "WAV, AIFF and other uncompressed types" is selected at File > Import > Audio? Or does it occur when the file type selector is set to QuickTime as well? Does this problem occur in 1.2? If so, a P3 might just be reasonable. If not, then the problem has gone unreported for years. I have however pointed to this bug in bug 35 (Occasionally unreliable importing of WAV and AIFF files) in case this issue is relevant to stability on Mac, though I doubt it.
(In reply to comment #1) Mac OS X 10.5.8 PPC. In 1.3.13, when selecting "Quicktime" in the Formats dropdown, CD tracks are greyed out. Importing with libsndfile and ffMPEG compatible files gives the same result - an extra 570 samples at the start. In 1.2.6, the extra 570 samples appear at the start.
Created attachment 47 [details] 46-second commercial CD track from gapless CD CD track dragged from the CD onto HD. Verified that the file on the HD is AIFF/sowt with offset by importing into 1.3.13
So the correct behavior is not to have any silence? I don't know much about this, but aren't there also cases where the the user might want it, (like when some cds have audio in the negative (below 0:00s, e.g. -0:08)? I remember having some audio cds that hid 'bonuses' like this, but I don't have any on hand to test if this goes in this part of the data.
(In reply to comment #4) > So the correct behavior is not to have any silence? If the CD had a hidden song in the pregap and the CD extraction tool was able to extract it, then I understand that it would extract as "Track 0" and so if that AIFF had an offset, the offset wouldn't be wanted. The offset also isn't wanted obviously if you drag a bunch of tracks on a gapless CD from Finder into Audacity. Can you remind me Bill is there any functional purpose in the silence added by the Finder extraction (which seems to amount to an extra CDDA frame)? Do other CD extraction tools on other platforms produce a file with an offset? Is offset being ignored for all files with all importers (i.e. Audacity is doing this, not the importer)? Or does only AIFF use offset? The case that occurs to me is ripping audio from DVDs or extracting from video files. These audio files usually have some milliseconds of delay important for video sync. Are we sure this isn't handled by a file offset? I don't think so (instead handled by metadata in the video file?) but we should be sure about this and any other possible cases there may be for retaining silence. Cool Edit Pro retains the silence FWIW.
(In reply to comment #5) I think we're confusing the issue in worrying about audio in the pause region (gap). FWIW, when importing from a CD with audio in the pause, the Finder serves up the track audio plus the audio in the following pause. When this is the case, most CD players will count up (displaying negative time) to zero, then count up from zero when the pause is finished. For example if there is audio in the pause at the start of track 3, the filed served up by the Finder will include the audio in track 2 and the audio in the pause at the start of track 3. I have verified this with a CD that does exactly that. Unfortunately, the extra 570 samples of silence are still there at the start of the imported audio. I have no idea if there is any functional purpose to the extra CDDA frame of silent audio. As our correspondent who first pointed this out to us has noted, an offset in the SSND chunk is a rare thing. I would hazard to guess that only Apple does this, and it's purpose will forever remain a mystery. I cannot test any importers other than iTunes and Audacity. It appears that Cool Edit Pro is being fooled as well. My take is that we don't want the silence. There is clearly an offset to the start of audio data specified in the SSND chunk. Yes, it's only 0.0129 seconds, but it shouldn't be there, and is audible (as a click) if you string two or more tracks together imported from a gapless live CD. The top of the AIFC file served up by the Finder looks like this: FORM 00F0 EBA8 AIFC FVER 0000 0004 A280 5140 COMM 0000 0018 0002 003C 38A0 0010 400E AC44 0000 0000 0000 736F 7774 0000 (note that 736F 7774 is "sowt") SSND - chunk data length: 00F0 EB70 - offset to start of sound samples: 0000 08E8 - block size: 0000 0000 When iTunes imports a file from a CD, it processes it and converts it to an AIFF. The top of the file looks like this: FORM 00F0 EB60 AIFF COMM 0000 0012 0002 003C 38A0 0010 400E AC44 0000 0000 0000 SSND - chunk data length: 00F0 E288 - offset to start of sound samples: 0000 0000 - block size: 0000 0000 Note that in the AIFF produced by iTunes the SSND chunk data length is shorter and the offset is 0. When the AIFF produced by iTunes is imported into Audacity, no audio is lost (other than the 570 samples of silence at the start), and tracks from gapless, live CDs string together perfectly.
(In reply to comment #6) As per my previous I'm probably OK with taking the offset into account in AIFC. We're not also suggesting reversing the byte order of AIFC on import and so converting it to AIFF are we? According to Wikipedia. http://en.wikipedia.org/wiki/Audio_Interchange_File_Format iTunes exported files are still AIFC (sowt). If to deal with the AIFC problem we have to take into account offsets in other formats (does AIFF potentially have offsets?) then I think it needs some research to confirm they don't have any valid use.
(In reply to comment #7) No, AFAICT the AIFFs exported/created by iTunes are not AIFC, do not have an offset, and do not have the reversed byte order. Wikipedia appears to be wrong. See the talk page on the referenced article. Apple has responded: "It's not actually "creating" little-endian AIFF/AIFC files, it's exposing virtual little-endian files b/c the audio data on the CD itself is little-endian. The underlying cdda filesystem synthesizes them when you mount a CD and make read requests to it, there aren't actually any files anywhere." See: http://lists.apple.com/archives/coreaudio-api/2009/Mar/msg00397.html Of course, this ignores what happens when you drag a track from a CD to the HD. In that case there really is a little-endian AIFC/sowt file created. When iTunes imports a CD track to AIFF, it throws out the 570 samples of silence and creates a big-endian AIFF in it's internal library. When iTunes imports an AIFC/sowt FILE from the HD, it simply copies the file into it's library. I assume that iTunes ignores the extra 570 samples when it plays the file. If, within iTunes, you convert that AIFC to Apple Lossless, then convert it to AIFF, you get a "real" big-endian AIFF with no offset. So my conclusion is that the 570 samples of silence at the start of the file are meant to be ignored/removed. Why else would there be the "offset to start of sound data"? SNDSampler http://www.sndsampler.com/ correctly discards the extra 570 samples when importing directly from a CD, and when opening an AIFC/sowt file from the HD. It is impossible to tell what Fission http://www.rogueamoeba.com/fission/ is doing since it doesn't zoom in to the sample level. -- Bill
(In reply to comment #8) I did some research on this and with Bill's comments I agree that the silence should go. the FLAC project appears to have fixed this (search for aiff and offset in http://flac.sourceforge.net/changelog.html) I also tried using the libsndfile interface, but the only command to get an offset (SFC_GET_EMBED_FILE_INFO) returns one of zero for the file you supplied. This appears to be a libsndfile bug, so I'm mailing their list (although I don't know how active it is.) If I don't get a response in a few days I'll just try to patch it and submit that to their list.
I think I fixed this. I submitted a patch to the libsndfile-users list, and am waiting for review before checking it in to audacity. In the meantime if someone wants to test here is patch (apply in lib-src directory.)
Created attachment 53 [details] fixes aiff offset importing
fixed with revision 10751. Also the patch was accepted upstream.
(In reply to comment #12) AFICs with offset import properly into Audacity 1.3.13-alpha-Oct 31 2010 on Mac, OS X 10.5.8 PPC.
(In reply to comment #13) Thanks, Bill, also for letting original complainant know. Suggest we resolve fixed in a few days if we hear nothing from him to the contrary.
(In reply to comment #14) > Thanks, Bill, also for letting original complainant know. Suggest we resolve > fixed in a few days if we hear nothing from him to the contrary. Nothing more heard and I confirmed also on Win that there is now no offset importing Bill's test file using libsndfile. Resolved fixed. Don't understand why Bill got offset importing via FFmpeg because on Win the FFmpeg importer took the offset into account. If FFmpeg on Mac ignores the offset then the bug will still be there because this patch was only for libsndfile. I think what you may be seeing is that the "FFmpeg-compatible files" filter in the OpenFile dialogue is now ignored on initialised .cfg, so that libsndfile would be used first for AIF(F).
