Hi Spoon,
I am evaluating dBpoweramp to replace my current CD media library curation process. While reviewing the outputs, I discovered a reproducible issue with dBpoweramp’s AAC encoder on macOS. It causes all .m4a files produced by Music Converter and CD Ripper to be branded incorrectly at the container level.
This is mostly cosmetic, as playback is unaffected, but technically incorrect, so I thought I'd point it out as I don't see it mentioned elsewhere.
Issue Summary
When encoding AAC (.m4a) on macOS using the built-in Apple CoreAudio AAC encoder, dBpoweramp is writing an MP4 (mp42) major brand rather than the correct M4A audio-only brand. It works properly with ALAC encoding, but not with AAC.
Encoded file EXIF data for AAC .m4a files:
MajorBrand : MP4 v2 [ISO 14496-14]
CompatibleBrands : mp42, isom
FileType : MP4
FileTypeExtension : mp4
MIMEType : video/mp4
Encoded file EXIF data for ALAC .m4a files:
MajorBrand : Apple iTunes AAC-LC (.M4A) Audio
CompatibleBrands : M4A , mp42, isom
FileType : M4A
FileTypeExtension : m4a
MIMEType : audio/mp4
This affects both CD Ripper → AAC (m4a) and Music Converter (and Batch) → AAC (m4a).
This causes ExifTool (and other parsers) to misclassify the files and could open the door for potential compatibility problems with tools that expect proper .m4a audio-only branding. Though most well behaved music players probably won't take issue with this; if they did, you'd probably have already addressed this.
Expected Behavior
For audio-only AAC with .m4a extension, the ftyp atom should use:
This is speculation, but based on the encoder settings metadata stored inside the file, it appears dBpoweramp is invoking afconvert using:
-f mp4f -s 3 -d aac -ue vbrq <value> -q 127 "[in]" "[out]"
Where it may need to use the following instead:
-f m4af -s 3 -d aac -ue vbrq <value> -q 127 "[in]" "[out]"
Reproduction Steps
Note: I am using MacOS Tahoe (26.1), but it is 100% reproducible for me.
exiftool -a -u -g1 -s <filename.m4a>
Exiftool shows mp42 Branding/Codec ID/Format in the container rather than M4A. Though it is correctly showing mp4a-40-2 in the audio stream itself.
Request
Update the AAC encoder wrapper on macOS so that .m4a output uses the correct M4A major brand. The ALAC encoder already does this correctly, so the AAC encoder should ideally behave the same way for consistency.
Happy to provide sample files before/after or run any test builds if needed.
Thanks!
I am evaluating dBpoweramp to replace my current CD media library curation process. While reviewing the outputs, I discovered a reproducible issue with dBpoweramp’s AAC encoder on macOS. It causes all .m4a files produced by Music Converter and CD Ripper to be branded incorrectly at the container level.
This is mostly cosmetic, as playback is unaffected, but technically incorrect, so I thought I'd point it out as I don't see it mentioned elsewhere.
Issue Summary
When encoding AAC (.m4a) on macOS using the built-in Apple CoreAudio AAC encoder, dBpoweramp is writing an MP4 (mp42) major brand rather than the correct M4A audio-only brand. It works properly with ALAC encoding, but not with AAC.
Encoded file EXIF data for AAC .m4a files:
MajorBrand : MP4 v2 [ISO 14496-14]
CompatibleBrands : mp42, isom
FileType : MP4
FileTypeExtension : mp4
MIMEType : video/mp4
Encoded file EXIF data for ALAC .m4a files:
MajorBrand : Apple iTunes AAC-LC (.M4A) Audio
CompatibleBrands : M4A , mp42, isom
FileType : M4A
FileTypeExtension : m4a
MIMEType : audio/mp4
This affects both CD Ripper → AAC (m4a) and Music Converter (and Batch) → AAC (m4a).
This causes ExifTool (and other parsers) to misclassify the files and could open the door for potential compatibility problems with tools that expect proper .m4a audio-only branding. Though most well behaved music players probably won't take issue with this; if they did, you'd probably have already addressed this.
Expected Behavior
For audio-only AAC with .m4a extension, the ftyp atom should use:
- MajorBrand: M4A
- CompatibleBrands: M4A mp42 isom (or similar Apple-standard sequence)
This is speculation, but based on the encoder settings metadata stored inside the file, it appears dBpoweramp is invoking afconvert using:
-f mp4f -s 3 -d aac -ue vbrq <value> -q 127 "[in]" "[out]"
Where it may need to use the following instead:
-f m4af -s 3 -d aac -ue vbrq <value> -q 127 "[in]" "[out]"
Reproduction Steps
Note: I am using MacOS Tahoe (26.1), but it is 100% reproducible for me.
- Rip any CD track to AAC (m4a)
- Or convert any ALAC file to AAC (m4a) via Music Converter
- Inspect the output with ExifTool, mediainfo, or what have you.
exiftool -a -u -g1 -s <filename.m4a>
Exiftool shows mp42 Branding/Codec ID/Format in the container rather than M4A. Though it is correctly showing mp4a-40-2 in the audio stream itself.
Request
Update the AAC encoder wrapper on macOS so that .m4a output uses the correct M4A major brand. The ALAC encoder already does this correctly, so the AAC encoder should ideally behave the same way for consistency.
Happy to provide sample files before/after or run any test builds if needed.
Thanks!

Comment