Hello!

I have read some posts regarding the following problem and everything seems to be in order, but I would like to be 100% sure.

I use EAC to copy my CDs together with LAME 3.90.3 using --alt-preset standard. In EAC, I have the following options for compression:



The resulting files seem to be in order (have bit rates from 128 to 320 ; somtimes 32 kbps frames are included).

Now, when using the options above, will the resulting MP3 file be an APS file? Basicly, will the quality of the MP3 have the same quality as "normal" APS files (when only --alt-preset standard is passed)?

Sebastian Mares

:'( Something makes me think the ones with EAC have a worse quality...

http://www.hydrogenaudio.org/forums/index....t=25#entry67461

OK, thanks... Everything seems to be fine then.

OK, I have just made a test: I created one MP3 using EAC and one MP3 using RazorLame. The decoded WAVs had different MD5 sums. Which one is now better?

A few possible reasons:
- dither/truncation applied on decoding
- different file length
- offset

Have you done a wave substraction (with manual offset correction before)? - What is the difference like?

I have decoded both MP3 files using RazorLame. Therefore, I don't think the decoding process should differ (one file has dithering while the other doesn't).
The file sizes were identical.

I have also tried doing a WAV compare with EAC, but it took so long, that I had to cancel it (after 15 minutes only one block of the progressbar was there). However, EAC told me that the positions it scanned so far had different samples.

Edit 1: Oh, and about offset... Do you mean the offset of the CD drive or the offset of the encoder/decoder? I think both MP3 files had the same offset, as the WAV I used to encode the RazorLame MP3 was created by EAC which is configured to have a read offset of +6.

Edit 2: The thread AtaqueEG posted covers only the bit rate. Notice that EAC is also configured to add CRC and uses "High Quality".

Edit 3: Before decoding the MP3s, I have removed all ID3 / APE tags.

Just made a small program in VB which should print the passed command line arguments:

I don't know if RazorLame uses dither anywhere. If yes: Dither = added low level noise before truncating to lower bit depth; noise = random data ...


I'd rather use a wave substraction. This way you can get an impression of what the differences are like. Audacity (free) or Nero Wave Editor should be able to do this.

If you want, you can upload the 1st ~30 seconds of both mp3 files here (use mp3directcut or something similar) and I'll have a look at them.


Both.


Why CRC? I thought this is a waste of bits. If razorlame doesn't add CRC probably this is the reason.

BTW: Why don't you use lame.exe with EAC: "User defined encoder"?

RazorLame uses LAME to decode files and LAME won't use dithering (as far as I know).




Give me 5 minutes.



I don't think that CRC matters. When decoding, CRCs should be ignored, as they are not part of the main data, not part of the ancillary data. They are placed after the header.



I did that already. I just wanted to know if the quality of the MP3s I already encoded is worse.

I've just done a small test using lame 3.90.3 (.exe) from commandline:

<1> --alt-preset standard
<2> --h -v -b 192 --alt-preset standard
<3> -p -h -v -b 192 --alt-preset standard

The outputs from 1 and 2 were identical; 3 was not. (different average bitrate, different bitrate distribution). The -p switch (= add CRC) is most likely the reason for the differences. You might want to re-try without.

Is there any tool which will remove the CRC from already encoded files?

The CRC is stored in the next two bytes after the frame header, so removing these (and also altering the CRC flag in the header) would do the job, I think.

I don't know. I don't see a reason what this could be useful for. If the CRCs are already there you can't improve anything (audibly) by removing them, can you?

Well, how come that with CRC, the decoded data is different than without CRC?

AFAIK the difference is caused by using bits for CRC on encoding that would be used for storing audible information otherwise (simplified).
In VBR mode probably in some cases less bits will be used for audible content, in other cases the encoder will switch to the next bitrate for a frame and use more bits (and/or store more in bit reservoir which can have an influence on the encoding of the following frames).

Ideally adding CRC in VBR mode should increase file size without changing audio-related content, but obviously this isn't the case. I've done a wave substraction in CEP with the mp3s I created (see above). Result:

OK, so the main question: are the MP3s with CRC worse than the ones without CRC? Would I need to re-encode the files?

Very good question. I don't know of any listening tests covering this. Maybe a developer could tell what's the difference in theory - Gabriel?

With crc on the files are likely to be worst, but this is very minimal.
When you enable it, some space is used to store the crc. In case of cbr, in each frame you are reducing quality, and in case of vbr when you are using a 320kbps frame the quality is reduced.


But this is very minimal: 2 bytes per frame, about 38 fps, so it is about 76 bytes per second.
My choice would be to not re-encode.