Hi, everyone Is there anybody with the experience to do the compliance test using ver 0.14.2b code ?! I use madplay to decode the compliance bitstream : he_mode.bit My output file is he_mode_intel_24.hex The output file generated by L3dec.exe is he_mode.hex.
The compliance test result : 251137 samples are compared. and the maximum difference :0.489849 the root mean square is 0.0619873
You can find the 11701th sample: the he_mode_intel_24.hex is 123809 the he_mode.hex is f1e918 It has exceeded the maximum difference accoring to the compliance test.
Also in 11702th ....
The result can't meet the full compliance request.
Also I doubt why the file size of output hex file is different with the hex file generated by l3dec.exe
the following is libmad build environment My configuration is FPM_INTEL,_LIB,HAVE_CONFIG_H,ASO_ZERO_CHECK,WIN32, _MBCS_DEBUG The decode command : -d -b 24 -o he_mode_intel.hex he_mode.bit
Can anyone give me the hints where I might go wrong?! PS : the file size of output hex file in FPM_ARM is also different with the output hex file in FPM_INTEL or the hex file gererated by l3dec.exe
I will attach the two hex file in another mail.
Best Regards, Sunny (Pei-Lin Tsai)
On Monday, October 14, 2002, at 05:43 PM, pltsai@globalunichip.com wrote:
Is there anybody with the experience to do the compliance test using ver 0.14.2b code ?! I use madplay to decode the compliance bitstream : he_mode.bit My output file is he_mode_intel_24.hex The output file generated by L3dec.exe is he_mode.hex.
The compliance test result : 251137 samples are compared. and the maximum difference :0.489849 the root mean square is 0.0619873
You can find the 11701th sample: the he_mode_intel_24.hex is 123809 the he_mode.hex is f1e918 It has exceeded the maximum difference accoring to the compliance test.
Also in 11702th ....
The result can't meet the full compliance request.
Please note: The only bitstream whose PCM output must match within tolerance to be compliant is the compl.bit stream. The other bitstreams help to detect potential problems, but they are only informative, not normative.
Also I doubt why the file size of output hex file is different with the hex file generated by l3dec.exe
The he_mode.bit bitstream tests the various stereo encoding modes. The reason you find different file sizes is likely because of these changing modes: frames 1-10 and 111-131 are single-channel; frames 11-20 are dual channel; frames 21-110 are stereo.
By default, 'madplay' only outputs the first channel in a dual channel stream, so you are losing the second channel output for comparison. You can force it to be output using -S (--stereo), but then the single-channel frames will have duplicate samples.
If you account for the expected number of channels in each frame, you should find MAD's output to be much closer to that of l3dec.
Rob, I'm interested in allowing my users to retag their files with older versions (I think I'll limit it to v2.3 or v2.4). Is there a way to get libid3tag to render a specific version? Is it as easy as changing the version in the tag header before rendering?
Thanks,
- Mark
On Friday, October 18, 2002, at 11:43 PM, Mark Malson wrote:
Rob, I'm interested in allowing my users to retag their files with older versions (I think I'll limit it to v2.3 or v2.4). Is there a way to get libid3tag to render a specific version? Is it as easy as changing the version in the tag header before rendering?
While it was a goal of the library to be able to read all versions of ID3v2 tags, it was not a goal to be able to write ID3v2 tags in obsolete formats. Consequently it is not supported; changing the version in the tag header will have no effect.
Arguably, since writing ID3v1 tags is supported, the library ought to support writing tags using any known version. Maybe it could be added.
-
Mark Malson -
pltsaiļ¼ globalunichip.com -
Rob Leslie