sbooth

The thing I don't understand is what exactly Stephen meant in his post. "...it is not longer 100% certain exactly what data is being sent to the DAC" makes it sound as though using Lion means that he cannot guarantee that the audio is bit-perfect. Sorry for being unclear. That is, in fact, precisely what I meant. Since in Lion it isn't possible to send non-mixable audio to a USB DAC (using the default Apple USB driver, which everyone does), it is up to the audio driver to convert the 32-bit floating point numbers a program sends to the format the DAC requires. Mathematically this is a very simple operation (just a multiply), but it is also possible that some sort of DSP, dither, noise shaping, mixing, etc. could be applied to the signal since the audio isn't marked as non-mixable.

I guess the problem is hog mode. Somehow hog mode is broken. Without hog mode, both PM and Audirvana can't enable integer mode either. Hog mode actually works just fine in Lion- it can still be taken so a device is owned exclusively by a single process. It is the non-mixable integer virtual formats that are not available in Lion. While hog mode is a prerequisite for non-mixable output, non-mixable output is not a requirement to use hog mode.

Developers of Amarra, Pure Music, Audirvana, and Decibel seem to have been totally and naively unaware that Lion might trash their audiophile niche. I'll point out that until yesterday Lion was under NDA, and anyone with access to the prerelease versions signed a legally binding agreement that they would not discuss or disclose anything about it to non-NDA individuals. To do so could mean, in the worst case, being barred as an Apple developer (which means no apps on the Mac or iOS App Stores) and possible legal action.

All of my tests have also confirmed that integer mode is no longer available on Lion. An audio device in OS X has two different formats of interest: the virtual format and the physical format. The virtual format is the format that all applications use to communicate with the device driver, while the physical format is the format that the device driver actually sends to the device. The device driver is responsible for converting between the virtual and physical formats, typically mixing system audio in a mix buffer before converting to the physical format and sending the audio out. My Wavelength Proton, for example, supports a 24-bit integer virtual format on Snow Leopard when hog mode is owned and the device is configured properly. In Lion, the only virtual format available, regardless of hog mode, is 32-bit float. The formats that Chris posted in his screenshot are the physical formats supported by the device. The best way to determine what the device supports is to use HALLab. I've posted screenshots for my Proton illustrating both the supported virtual and physical formats.

I'm pretty confident that I read Max's developer, Stephen Booth (sbooth), himself recommending XLD to someone about to begin a ripping project, recently. That isn't correct. While XLD is certainly excellent software, I typically recommend Rip over Max for new ripping projects because of its AccurateRip support. I have never recommended nor discouraged use of XLD.

We can, and in fact have, measured and recorded an acoustic difference in the playback of WAV and AIFF files. In the playback. We have, with even more certainty, found that the data in an AIFF file and a WAV file is not unexpectedly, exactly the same. I find this intriguing. Can you elaborate on what the differences were? Do you have any pointers to the study or results that I could peruse?

Until Lion is released it is under NDA, so I don't think anyone will discuss it in a public forum.

I purchased a new MacBook Pro (MacBookPro8,2) a few months ago and replaced the optical drive with a 120 GB OCZ Vertex 2. I chose to install OS X on the SSD and moved my home folder and music to the 500 GB internal drive. The speed is unbelievable- the typical time from when I press the power on button to when I'm typing my password is 5-6 seconds. I haven't had any reliability issues whatsoever. I was worried initially about systems hangs or freezes, or failure to wake from sleep, but in months of extensive use I have had perhaps 3 or 4 problems.

I want to clarify one point about what integer mode (or integer playback) means in the context of Decibel. The term is becoming popular but it lacks a concise definition, so there can be some confusion on its meaning in various contexts. If exclusive access is enabled and the DAC supports integer input, Decibel will send audio to the DAC as integers. In exclusive mode, as the name implies, Decibel has complete control over the audio device and what audio is sent to it. Internally Decibel represents audio as floating point numbers. This isn't a problem because all "normal" sized integer audio samples can be converted to and from floating-point numbers 100% reversibly and with 100% accuracy. What Charlie means by fixed integer in his post above is an all integer audio playback chain. Take a plain WAVE file on disk- in an all integer chain the audio will be read as an integer from the file, perhaps bit shifted left, and then sent to the DAC as an integer. There are no conversions to or from floating point. The end result, however, is the same- the same bits are sent to the DAC. Some early versions of AyreWave had an all integer playback chain, but I shifted to the floating point intermediate when I added support for more DACs and digital volume.

I'll file a bug report as well. If I sounded disenchanted with the idea it's just that it has been my experience that filing bugs with Apple feels like submitting things to a black hole. You may hear back, you may not, and if you do it might not be for months or even years.

It says the file contains 8192 frames. In this case that is correct- the file does contain 8192 audio frames, but 4096 are remainder frames which should be discarded by the decoder.

OK, I see what you're referring to now. Those numbers are in the mvhd, tkhd, and mdhd boxes. I broke down the numbers using ISO 14496-12 as a guide. Here is what I came up with: For reference, the number of valid audio frames in the file is 0x1000 The moov.mvhd duration is set to 0x2000 The moov.trak.tkhd duration is set to 0x2000 The moov.trak.mdia.mdhd duration is set to 0x2000 So, from the standpoint of ISO 14496-12 that is all that can be determined, and it does appear that the information is incorrect. The audio type is specified in the moov.trak.mdia.minf.stbl.stsd box. This tells that the contents are of type alac, but other than that nothing can be known because Apple has not made the format of that box public. It is fairly common knowledge that the moov.trak.mdia.minf.stbl.stsd.alac.alac contains the decoder specific data- in this case it contains the priming and remainder frames, among other things. I think that Charlie is right- since Apple Lossless is a proprietary format with no public specification, so there isn't much that can be done. I would guess that iTunes writes the ISO 14496-12 items correctly because although it uses the same underlying codec to encode the audio, it has a different file generator that operates more correctly. I've actually files bugs related to this (tangentially) since 2006, and some of them are still around. It's definitely not an ideal situation.

I wasn't able to duplicate this problem. I generated a 4,096 frame mono wav in Audacity, and converted it to m4a using afconvert. The resulting alac file does contain 8,192 frames, but only 4,096 are audio and the rest are remainder. I converted back to a wav with afconvert and got a wave file with 4,096 frames. $ afinfo ~/Desktop/4096.wav File: /Volumes/Home/sbooth/Desktop/4096.wav File type ID: WAVE Data format: 1 ch, 44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer no channel layout. estimated duration: 0.092880 sec audio bytes: 8192 audio packets: 4096 bit rate: 705600 bits per second packet size upper bound: 2 audio data file offset: 44 optimized source bit depth: I16 $ afconvert -f m4af -d alac ~/Desktop/4096.wav ~/Desktop/4096.m4a $ afinfo ~/Desktop/4096.m4a File: /Volumes/Home/sbooth/Desktop/4096.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: 0.092880 sec audio bytes: 3158 audio packets: 2 audio 4096 valid frames + 0 priming + 4096 remainder = 8192 bit rate: 136003 bits per second packet size upper bound: 3150 audio data file offset: 4096 optimized source bit depth: I16 $ afconvert -f WAVE -d LEI16 ~/Desktop/4096.m4a ~/Desktop/foo.wav $ afinfo ~/Desktop/foo.wav File: /Volumes/Home/sbooth/Desktop/foo.wav File type ID: WAVE Data format: 1 ch, 44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer no channel layout. estimated duration: 0.092880 sec audio bytes: 8192 audio packets: 4096 bit rate: 705600 bits per second packet size upper bound: 2 audio data file offset: 4096 optimized source bit depth: I16

I've posted the second prerelease of version 1.2.3, still available from the same URL: http://dl.dropbox.com/u/21004626/Decibel-1.2.3-prerelease.zip I believe it fixes most of the problems people are experiencing.

I'd like to expand testing of Decibel to a wider pool of testers before official releases. If anyone would like to test a pre-release version of Decibel 1.2.3, I've posted a build at http://dl.dropbox.com/u/21004626/Decibel-1.2.3-prerelease.zip The notes documenting changes are at http://sbooth.org/Decibel/release_notes/1.2.3.html I would appreciate hearing of any issues discovered, either via e-mail or a note here.