Using the ACM, you won't have to pay the $15,000 FhG require. Here's a complete working project, you can directly use the provided function. This is an asm translation of David Weekly's C code.
You can get my base.inc from the OOP forum, in the "Fixed TIX/ATC" thread.
With some changes you can use any codec to encode/decode audio files, even .ogg have an ACM codec.
keywords: acm, mp3, decode, decompress, wav, wave, source
You can get my base.inc from the OOP forum, in the "Fixed TIX/ATC" thread.
With some changes you can use any codec to encode/decode audio files, even .ogg have an ACM codec.
keywords: acm, mp3, decode, decompress, wav, wave, source
what is ACM? :?
google didn't tell me much :(
google didn't tell me much :(
ACM means Audio Compression Manager, and it's about CODECS (compressor/decompressor) for various wave formats - like mp3, ogg, ...
As the attachment was lost, I'm uploading it again
Also, to play-back the decompressed sound (either after or during decompression) :
http://www.asmcommunity.net/board/index.php?topic=22355.0
http://www.asmcommunity.net/board/index.php?topic=22355.0
I can't fully grasp the code.For example let's say that I have a MP3 at resource I want to play. So I have to unpack it to memory I guess. How can I allocate a memory that don't know the size? Could you throw an example playing MP3 by using your codes. Thanks
You know the size of the resource:
LoadResource
LockResource
SizeofResource
See the "mov f1,fopen(MP3File,"rb")" , "invoke ReadFile,f1,addr mp3buf,522,addr baka,0" , and "invoke CloseHandle,f1" lines? You replace there
Also, for starters, use a 128kbps stereo mp3.
You can make a linked-list of chunks, a resizable flat array, or a vector of chunks. - for the output. Please look around how to use such structures.
LoadResource
LockResource
SizeofResource
See the "mov f1,fopen(MP3File,"rb")" , "invoke ReadFile,f1,addr mp3buf,522,addr baka,0" , and "invoke CloseHandle,f1" lines? You replace there
Also, for starters, use a 128kbps stereo mp3.
You can make a linked-list of chunks, a resizable flat array, or a vector of chunks. - for the output. Please look around how to use such structures.
It's not necessary to decode the entire MP3 at once - we can STREAM the data , decompressing and playing it as required.
The secret is the ACMSTREAMHEADER structure.
In order to convert audio from one format to another, ACM requires that we set up at least two of these (one per audio format). Note that one of the fields of this struct is a pointer to a buffer...Especially interesting is the ACMPrepareHeader function, which we need to call at least once to tell ACM about the buffer.
If, for example, we wanted to convert MP3 data into PCM/WAV data (which we can play), we need a source stream whose buffer holds one chunk of mp3 data, and a target stream whose buffer holds the decompressed pcm/wave data.
Guess which buffer we play?
Note that these buffers are relatively small, usually only large enough to store around one second of audio data (or less).
So it really doesn't matter how large the MP3 file is, we're more interested in how large the input and output buffers must be, and that depends on how long (in seconds) we want to buffer, and the bitrate (quality) of the data etc.
Say we want output at 44,100 samples per second, in MONO, at 16 bit resolution. The output buffer would need to be 88,200 bytes in order to hold one second of audio data (16 bit = 2 bytes per sample, and at 44,100 samples per second we need 88,200 bytes). Stereo output at this bitrate and resolution would require a buffer twice as large (it's not really well known, but for stereo output into a single buffer, we get the left channel in the first half of the buffer, and the right channel in the second half of the buffer).
More information available apon request, but I found the ACM example sourcecode (in C) posted on MSDN to be useful.
The secret is the ACMSTREAMHEADER structure.
In order to convert audio from one format to another, ACM requires that we set up at least two of these (one per audio format). Note that one of the fields of this struct is a pointer to a buffer...Especially interesting is the ACMPrepareHeader function, which we need to call at least once to tell ACM about the buffer.
If, for example, we wanted to convert MP3 data into PCM/WAV data (which we can play), we need a source stream whose buffer holds one chunk of mp3 data, and a target stream whose buffer holds the decompressed pcm/wave data.
Guess which buffer we play?
Note that these buffers are relatively small, usually only large enough to store around one second of audio data (or less).
So it really doesn't matter how large the MP3 file is, we're more interested in how large the input and output buffers must be, and that depends on how long (in seconds) we want to buffer, and the bitrate (quality) of the data etc.
Say we want output at 44,100 samples per second, in MONO, at 16 bit resolution. The output buffer would need to be 88,200 bytes in order to hold one second of audio data (16 bit = 2 bytes per sample, and at 44,100 samples per second we need 88,200 bytes). Stereo output at this bitrate and resolution would require a buffer twice as large (it's not really well known, but for stereo output into a single buffer, we get the left channel in the first half of the buffer, and the right channel in the second half of the buffer).
More information available apon request, but I found the ACM example sourcecode (in C) posted on MSDN to be useful.
Hi there, interesting discussion/project.
BTW can you implement a "pure assembly" MP3 decoder ?
If so, keep in consideration the M.A.D.: MPEG Audio Decoder that:
Hope that helps (or at least inspires).
BTW can you implement a "pure assembly" MP3 decoder ?
If so, keep in consideration the M.A.D.: MPEG Audio Decoder that:
is a high-quality MPEG audio decoder. It currently supports MPEG-1 and the MPEG-2 extension to lower sampling frequencies, as well as the de facto MPEG 2.5 format. All three audio layers — Layer I, Layer II, and Layer III (i.e. MP3) — are fully implemented.
MAD does not yet support MPEG-2 multichannel audio (although it should be backward compatible with such streams) nor does it currently support AAC.
MAD has the following special features:
Because MAD provides full 24-bit PCM output, applications using MAD are able to produce exceptionally high quality audio. Even when the output device supports only 16-bit PCM, applications can use the extra resolution to increase the audible dynamic range through the use of dithering or noise shaping.
Because MAD uses integer computation rather than floating point, it is well suited for architectures without a floating point unit. All calculations are performed with a 32-bit fixed-point integer representation.
Because MAD is a new implementation of the ISO/IEC standards, it is unencumbered by the errors of other implementations. MAD is not a derivation of the ISO reference source or any other code. Considerable effort has been expended to ensure a correct implementation, even in cases where the standards are ambiguous or misleading.
OSI Certified Open Source SoftwareBecause MAD is available under the terms of the GPL, it can be freely used in other GPL software, and is also available for immediate evaluation prior to obtaining a commercial license. (Please contact us to discuss commercial licensing terms.)
MAD does not yet support MPEG-2 multichannel audio (although it should be backward compatible with such streams) nor does it currently support AAC.
MAD has the following special features:
[*] 24-bit PCM output
[*] 100% fixed-point (integer) computation
[*] completely new implementation based on the ISO/IEC standards
[*] available under the terms of the GNU General Public License (GPL)
Because MAD provides full 24-bit PCM output, applications using MAD are able to produce exceptionally high quality audio. Even when the output device supports only 16-bit PCM, applications can use the extra resolution to increase the audible dynamic range through the use of dithering or noise shaping.
Because MAD uses integer computation rather than floating point, it is well suited for architectures without a floating point unit. All calculations are performed with a 32-bit fixed-point integer representation.
Because MAD is a new implementation of the ISO/IEC standards, it is unencumbered by the errors of other implementations. MAD is not a derivation of the ISO reference source or any other code. Considerable effort has been expended to ensure a correct implementation, even in cases where the standards are ambiguous or misleading.
OSI Certified Open Source SoftwareBecause MAD is available under the terms of the GPL, it can be freely used in other GPL software, and is also available for immediate evaluation prior to obtaining a commercial license. (Please contact us to discuss commercial licensing terms.)
Hope that helps (or at least inspires).
but for stereo output into a single buffer, we get the left channel in the first half of the buffer, and the right channel in the second half of the buffer).
Actually left/right samples are stored interleaved.
sample struct
left dw ?
right dw ?
sample ends
AllSamples sample NUM_SAMPLES dup (<>)
instead of
AllSamples struct
left dw NUM_SAMPLES dup (?)
right dw NUM_SAMPLES dup (?)
AllSamples ends
MAD has more than enough of its codebase in asm, iirc. One might only want to optimize the bit-fetching (from file/memory) code into asm.