Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3val: Safe to use? (Read 9613 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3val: Safe to use?

Hi all,

Is MP3val absolutely safe to use on my MP3s?

I'm asking because I've read about some kind of corruption of LAME's header can occur, to be exact the information needed for gapless/seamless play . I've read about it on this forum:

http://www.hydrogenaudio.org/forums/index....st&p=594705

Is this true? Can MP3val really corrupt that information when it fixes files?

Thanks in advance for your answers.

MP3val: Safe to use?

Reply #1 –
 

100 readers and not one reply? I thought this was the place to ask stuff like that..

Sorry if this has been discussed before but I couldn't find an *clear* answer to my question with the search.

Anyone?

MP3val: Safe to use?

Reply #2 –
I've never heard of mp3val, but depending on what your trying to do, could you:
1) Just have it check the files but not repair them?
or
2) Make the mp3 files read-only, and the mp3val should not be able to make changes.

Again, I know nothing about the software, but those may be a few things to experiment with...

MP3val: Safe to use?

Reply #3 –
Couldn't you just make copies of the MP3s you want it to work on and then have it modify the copies?

If it works well to your satisfaction, you can replace the original MP3s with the copies, or however you want to do it.

If it doesn't work well, or to your satisfaction, you can just delete the copies, and still have the original MP3s untouched.

MP3val: Safe to use?

Reply #4 –
I was the OP in the earlier thread. You can try it yourself -- run Mp3val on your own gapless files -- files produced by Lame 3.97 and earlier get affected, but not 3.98.1 (the bug was with Lame, not Mp3val; do a forum search to check). Since the gapless values get altered, all albums with seamless transitions are audibly affected.

MP3val: Safe to use?

Reply #5 –
Have you tried foobar2000? Does it cause the same problem? Maybe foobar2000 is aware of the lame problems and fixes the files completely.


On the other hand fb2k 0.9.6b1 corrupted my MP3 files when applying replygain. I haven't checked yet if it is fixed in current version.

MP3val: Safe to use?

Reply #6 –
Quote from: vlada on
On the other hand fb2k 0.9.6b1 corrupted my MP3 files when applying replygain. I haven't checked yet if it is fixed in current version.
In what way specifically did it corrupt the files? Did you write a more comprehensive bug report back then? ReplayGain scanner in fb2k should simply write the TXXX replaygain_* tags with the relevant information. I think there would be quite a bit more panic on this forum if RG scanning in fb2k was randomly corrupting the input files.
Full-quoting makes you scroll past the same junk over and over.

MP3val: Safe to use?

Reply #7 –
Quote from: euphonic on
I was the OP in the earlier thread. You can try it yourself -- run Mp3val on your own gapless files -- files produced by Lame 3.97 and earlier get affected, but not 3.98.1 (the bug was with Lame, not Mp3val; do a forum search to check). Since the gapless values get altered, all albums with seamless transitions are audibly affected.


I can confirm that MP3VAL breaks gapless information as described above. The gapless information remains intact after MP3VAL "fixes" the file, but it is no longer correct with respect to the other changes that MP3VAL makes to the file.

So what's the solution? My feeling is that you can/should only use MP3VAL if you know for sure that a file is really broke - bad enough to where there may be audible glitches, and/or doesn't play gapless anyway, or is not a requirement for that track.

But if you allow MP3VAL to go hog wild on your whole library, you may be breaking stuff that already works.

I am not so sure that MP3VAL always wants to fix files produced by LAME 3.97 and earlier. Seems to me it has to be even an older version of LAME. For example, MP3VAL tried to "fix" files encoded with LAME 3.93, but not others that were encoded with LAME 3.96. Files were VBR in both cases.

The real test is to check the gapless play with Foobar, as it really does use LAME header info to accomplish the gapless playback. I can tell you for a fact that I have MP3s that play gapless in Foobar BEFORE being "fixed" by MP3VAL. After they were fixed, then there was a slight noticeable gap upon playback.

I also noticed that EncSpotPro shows the LAME tag is gone after the file is fixed with MP3VAL. Not sure what that means. Just the XING tab is visible after MP3VAL fixes the file.

Interestingly enough, this isn't a problem with iTunes, as I have discovered in the past that iTunes does NOT use the LAME headers of MP3s to support gapless. iTunes relies on the fact that, assuming an MP3 was encoded from a WAV that was ripped from an audio CD, and that WAV had a multiple of 588 samples (tracked on CD sector boundaries), then iTunes will calculate that out and play it gapless.

So if you really want to "test" the gapless ability from LAME headers alone (before and after MP3VAL fixes), then you need to test with a player that really does use the LAME headers for gapless playback, such as foobar.

I mostly use iTunes, but if I have a TON of MP3s that play gapless in Foobar as well, then I do NOT want Mp3VAL breaking all my LAME gapless info.

My conclusion is that MP3VAL is a very useful tool for analysis, but it should be used as a "read only" process, rather than used to actually allowing it to fix your whole library. In sever cases when you know the MP3 is really bad (such as audible playback issues, which can be caused by problems in the headers), then in that case, go ahead and use MP3VAL. I have seen where MP3VAL can fix files that once had audible glitches in them, due to tagging programs that mucked up the headers.

Fortunately, I backed up my library before I let MP3VAL "fix" ALL the files it found errors with. Now I am in the process of restoring the whole library and getting back to where I was before I ran MP3VAL. In this case, it did a LOT more harm than good.

Mp3VAL does make .bak files of all the MP3s, but at that point, my database was so messed up and confused that it was easier to just do a full restore.

I can't totally blame Mp3VAL because, as it was pointed out above, the real root cause is that older versions of LAME did not put 100% accurate data in the headers. However, even though that is the case, it does NOT cause playback problems, and gapless still works with Foobar. So there is no perfect solution. I feel that if you have MP3 files encoded with older versions of LAME, it is better to just leave them "as is", and allow gapless to keep working right, rather than allow MP3VAL to "fix" the headers, which in some ways makes the file and the headers more consistent with each other, but the tradeoff is a high price - gapless will be broken in players that specifically rely on the LAME headers.

-Bill

MP3val: Safe to use?

Reply #8 –
Quote from: Straightbourbon on
I have discovered in the past that iTunes does NOT use the LAME headers of MP3s to support gapless.

iTunes scans for info in the Lame header (if it exists) and uses this information for gapless playback, so what you are saying is not exactly true.

Quote from: Straightbourbon on
iTunes relies on the fact that, assuming an MP3 was encoded from a WAV that was ripped from an audio CD, and that WAV had a multiple of 588 samples (tracked on CD sector boundaries), then iTunes will calculate that out and play it gapless.

Where did you read this?  I'm pretty certain that this isn't true either.

Quote from: Straightbourbon on
So if you really want to "test" the gapless ability from LAME headers alone (before and after MP3VAL fixes), then you need to test with a player that really does use the LAME headers for gapless playback, such as foobar.

You're better off decoding with foobar or Lame 3.98 or newer and looking at the wave files in an editor.

MP3val: Safe to use?

Reply #9 –
Quote from: Straightbourbon on
iTunes relies on the fact that, assuming an MP3 was encoded from a WAV that was ripped from an audio CD, and that WAV had a multiple of 588 samples (tracked on CD sector boundaries), then iTunes will calculate that out and play it gapless.

This has nothing to do with gapless playback of MP3s.  Gapless playback relies on the decoder knowing exactly how many samples of digital silence were added to the beginning and end of the original PCM audio stream by the encoder, and then deleting those samples.

The number of samples added at the beginning - encoder delay - is specific to each encoder (LAME's value is 576), and the number of samples added at the end - padding - varies depending on the length of the incoming PCM stream.  These are the values that are written to the LAME and/or XING tag and then read by the decoder upon playback.

How many samples were contained in the original PCM stream - and how they were partitioned - is irrelevant.
"Not sure what the question is, but the answer is probably no."

MP3val: Safe to use?

Reply #10 –
Quote from: greynol on
iTunes scans for info in the Lame header (if it exists) and uses this information for gapless playback, so what you are saying is not exactly true.

I could see iTunes scanning for LAME headers first, then trying "Plan B" for gapless after that. For example, I know stuff with good LAME headers plays gapless in iTunes and Foobar. But stuff with bad LAME headers (or whatever gets broken with MP3VAL) will have gaps in foobar, but none in iTunes. (At least, none that I could tell by listening.)

Quote from: greynol on
Quote from: Straightbourbon on
iTunes relies on the fact that, assuming an MP3 was encoded from a WAV that was ripped from an audio CD, and that WAV had a multiple of 588 samples (tracked on CD sector boundaries), then iTunes will calculate that out and play it gapless.

Where did you read this?  I'm pretty certain that this isn't true either.

Well, no one believes me on this one, so I was hesitant to even mention it. This is actually true in iTunes, whether it be an MP3 file or a WAV.

A great way to test this is to rip your favorite "gapless" CD into iTunes using WAV encoder. Listen to the WAVs and at this point, they should most certainly be gapless. Now delete those out of iTunes library, and go back to each WAV file with a WAV editor. Take a few samples out of the middle of each track so that each WAV file that you ripped from CD contains a number of samples that is no longer a multiple of 588 (1/75th of a second - CD sector size.)

Now import those WAVs into iTunes. Guess what? You now have gaps between tracks.

I first stumbled upon this fact when ripping an entire DAT tape into the computer. I wanted to break it up into tracks, but since I had no intention of ever burning to CD, I did not track on sector boundaries. Much to my surprise, the show had gaps when played back in iTunes. Even in WAV format.

So I went back to the original huge WAV file that was ripped from the DAT tape, and I loaded it into CDWAV. After tracking on sector boundaries and re-importing, the show played back gapless.

This even works / does not work at 48khz too. (CD sector boundary is an equivalent of 640 samples at 48 khz.) iTunes supports WAVs (and MP3s) at 48khz just fine. But if your track does not contain a multiple of 640 samples exactly, there will be a gap.

The only way to prove this all for sure would be to see the iTunes source code. But I believe my tests provide some pretty strong evidence, short of having the source.

If you think about it - iTunes expects the users to load audio CDs into their program. It seems like a fair assumption on iTunes part that any audio track would originate from an audio CD, and thus be tracked on sector boundaries. Sure, every once in a while someone might try what I did and rip some DATs and not track on sector boundaries, but that is so unusual that Apple probably figured that they could exploit the fact that 99.9% of tracks loaded into iTunes ARE tracked on sector boundaries, and not worry much about the rest.

Of course, if anyone knows any other reason why WAV files not tracked on sector boundaries would not play back gapless in iTunes, then I would like to know what it is. With WAVs, we don't need to worry about LAME headers or encoder delays. It's pretty straightforward that the first sample of the next track should immediately follow the last sample of the previous track, regardless of whether the samples are a multiple of 588 or not. But that is not what happens.

Quote from: greynol on
You're better off decoding with foobar or Lame 3.98 or newer and looking at the wave files in an editor.

I would agree that decoding to WAV would be the more precise way of doing it. However, I am such a stickler for gapless playback that I can pretty reliably detect even the slightest gap between songs. It's one of my pet peeves.

-Bill

MP3val: Safe to use?

Reply #11 –
Quote from: mixminus1 on
Quote from: Straightbourbon on
iTunes relies on the fact that, assuming an MP3 was encoded from a WAV that was ripped from an audio CD, and that WAV had a multiple of 588 samples (tracked on CD sector boundaries), then iTunes will calculate that out and play it gapless.

This has nothing to do with gapless playback of MP3s.  Gapless playback relies on the decoder knowing exactly how many samples of digital silence were added to the beginning and end of the original PCM audio stream by the encoder, and then deleting those samples.

The number of samples added at the beginning - encoder delay - is specific to each encoder (LAME's value is 576), and the number of samples added at the end - padding - varies depending on the length of the incoming PCM stream.  These are the values that are written to the LAME and/or XING tag and then read by the decoder upon playback.

How many samples were contained in the original PCM stream - and how they were partitioned - is irrelevant.


Can you be 100% sure that the code was written exactly that way for ALL decoders? Can you be sure that iTunes does not consider the number of samples, and attempt to do something more fancy with the CD sector boundaries in the absence of LAME ENC_PADDING headers?

What about WAV files in iTunes? Let's eliminate the MP3 issue entirely and just test WAV files. In iTunes, if your WAVs are tracked on sector boundaries, then they will play gapless. If the samples in the file are not a multiple of 588 at 44.1 khz (or 640 samples at 48 khz), then there will be audible gaps between the tracks.

Technically, a decoder should do it the way you described. But not by law. It's just code. They can write it to do whatever they want.

All I know is that I accidentally stumbled upon the "number of samples in file" issue in iTunes, and it is true with MP3s and WAVs that they must be tracked on sector boundaries, or you will get a gap - regardless of the LAME headers, which of course, do not exist in WAV files.

I also noticed in iTunes that MP3s that were not encoded by LAME and do not have any ENC_PADDING info in them also play back gapless, even though they do not in Foobar.

That is where I am thinking that iTunes must use some kind of "Plan B" to play back gapless in the absence of LAME headers, and it seems pretty clear to me at this point that the number of samples in the file has something to do with it.

Like I say - in iTunes - just try it yourself. WAV files (or MP3 files - regardless of LAME headers or not) play gapless if tracked on CD sector boundaries. If not, you get gaps. It must be in the code somewhere.

-Bill

MP3val: Safe to use?

Reply #12 –
I just imported a set of wave files into iTunes that do not end on sector boundaries.  Guess what, they played back gaplessly!

I think your analysis is somewhat erroneous, Bill.  I suggest you look over the discussion on this forum that covers Apple's implementation of gapless playback before jumping to conclusions over your tests and presenting these conclusions as fact.

MP3val: Safe to use?

Reply #13 –
Quote from: greynol on
I just imported a set of wave files into iTunes that do not end on a sector boundaries.  Guess what, they played back gaplessly!

I think your analysis is somewhat erroneous, Bill.  I suggest you look over the discussion on this forum that covers Apple's implementation of gapless playback before jumping to conclusions over your tests and presenting these conclusions as fact.


Looks like we are getting different results from our tests. Now what? Drill down to iTunes version, OS level, etc.?

I am not intending to present anything as fact. But there is something going on here, and I would like to find out what it is. If you can help, then that would be great!

Keep in mind that the original purpose of my post was to help confirm that MP3VAL does indeed mess up gapless playback for some MP3 files that previously played back gapless before being "fixed" by Mp3VAL.

If iTunes is indeed using the "standard" methods that foobar uses to detect gapless playback, then why is it that MP3s that once played back gapless in iTunes AND foobar only play back gapless in iTunes after the MP3VAL "fix", but now have gaps in foobar?

That was what I was originally responding to.

Quote from: euphonic on
I was the OP in the earlier thread. You can try it yourself -- run Mp3val on your own gapless files -- files produced by Lame 3.97 and earlier get affected, but not 3.98.1 (the bug was with Lame, not Mp3val; do a forum search to check). Since the gapless values get altered, all albums with seamless transitions are audibly affected.


As far as "facts" go, I have many VBR MP3s that were encoded with LAME 3.96, and MP3VAL found no errors in them. So I believe that the above quote is not completely accurate with regards to what LAME versions had the issue, but still, true enough that MP3VAL will find the errors in some older versions of LAME, and when MP3VAL "fixes" them, it breaks gapless playback in Foobar.

But NOT in iTunes!

So if iTunes is really looking at the LAME headers, and those headers no longer match what MP3VAL "fixes" in these files, why then does iTunes STILL play them back gapless while foobar does not?

My point is, there is not a blanket method that all decoders use to playback gapless. If that were a standard, then there would not exist such an example of Mp3s that do not play back gapless in one decoder, but do in another.

All I am saying is, there must be some different method that iTunes uses to detect gapless vs. Foobar.

My evidence is:
1) WAV files not tracked on sector boundaries do not playback gapless in iTunes
---    a) 'greynol' could not recreate this result
---    b) could be due to version of iTunes or version of OS - we don't know why at this point
---    c) Is there a way to trade WAV files? 30 second samples won't work for this.

2) MP3 files "fixed" by MP3VAL:
---    a) Do NOT playback gapless (anymore) in foobar, even though they did before
---    b) STILL playback gapless in iTunes
---    c) leads me to believe different gapless detection methods are used between the 2 softwares

-Bill

MP3val: Safe to use?

Reply #14 –
iTunes grabs the values from Lame headers and stores all of them in a separate database.  These values are not altered unless iTunes is somehow forced to re-detect gapless information.  While there may be other methods, the only one I know is to clear the information from the database by removing the files from the library and then re-import them.

I will gladly test wave files on any version of iTunes I have at my disposal, from 7 on up for 32-bit Windows if you like, though I am completely confident that I will not see any deviation from what I just reported.  There really is no point in altering files without also re-importing them because of the separate database that iTunes keeps.

Between what I've mentioned here and what is in the discussion I linked earlier(*), there should be no mystery as to why you are seeing MP3val behave differently between foobar2000 and iTunes.

(*) To save you some reading, the discussion seems to indicate that iTunes will search for additional silence at the edges of mp3 tracks in the event that the tracks do not contain gapless information that is either tagged when encoded by iTunes or inside a Lame header.  There is absolutely no evidence that iTunes makes an assumption that tracks will end on frame boundaries, even if it did, how would it know what the initial delay is for the mp3 file, since different codecs introduce different delays?  Gapless playback of mp3 files requires knowing both the correct starting point as well as the correct ending point.

MP3val: Safe to use?

Reply #15 –
Quote from: greynol on
iTunes grabs the values from Lame headers and stores all of them in a separate database.  These values are not altered unless iTunes is somehow forced to re-detect gapless information.  While there may be other methods, the only one I know is to clear the information from the database by removing the files from the library and then re-import them.

Between what I've mentioned here and what is in the discussion I linked earlier, there should be no mystery as to why you are seeing MP3val behave differently between foobar2000 and iTunes.


Ah, thanks! That answers the question. I tested that by re-importing into iTunes some of the MP3s that were "fixed" by MP3VAL, and sure enough, they do NOT playback gapless in iTunes anymore.

So the conclusion would have to be, do NOT use MP3VAL to fix all your MP3s because it will break gapless playback in those files. But since iTunes stores that information in a separate database, you won't notice it there until you re-import the tracks.

Quote from: greynol on
I will gladly test wave files on any version of iTunes I have at my disposal, from 7 on up for 32-bit Windows if you like, though I am completely confident that I will not see any deviation from what I just reported.  There really is no point in altering files without also re-importing them because of the separate database that iTunes keeps.


I tested this once again by importing WAV files of both 44.1 khz and 48khz that do not track on sector boundaries. They did indeed play gapless in the current version of iTunes. Since I no longer have the version of iTunes in which I first noticed these having gaps, I can't go back and test that again, and I do not even recall what version that was.

I am willing to concede that iTunes does not rely on CD sector boundary information for gapless, and I am glad that someone was able to correct me on that.

But it nice to now have an answer (above) to the broader issue of what iTunes is doing differently to play back the MP3s gapless that were broken by MP3VAL, whereas foobar now has gaps.

Seems better to NOT fix the older LAME encoded files with MP3VAL. Even though the headers may not be 100% correct to MP3VAL, it is better to have gapless still work in foobar, and in iTunes, if you ever wanted to re-import the files.

In a related topic, I did however notice that some non-LAME encoded MP3s that I have playback gapless in iTunes (even without the LAME headers), but not gapless in foobar.

   - I have 320 kbps (CBR) MP3 files of Pink Floyd's Division Bell. These were encoded with a non-LAME MP3 encoder, and have no LAME headers. There is no encoder padding information? (Foobar reports an encoder delay of 0, and EncSpot reports no LAME headers present.) When I play these in foobar, there IS a gap, as is to be expected. Foobar would presumably NOT be able to play these gapless because foobar relies on the LAME headers for gapless, and there are none.

   However, iTunes DOES play these file gapless! In the absence of any LAME headers or other encoder padding details, is iTunes successfully employing a DIFFERENT strategy than foobar to play these gapless? Does it try and do something fancy when the LAME headers are absent?

 

MP3val: Safe to use?

Reply #16 –
Quote from: Straightbourbon on
However, iTunes DOES play these file gapless! In the absence of any LAME headers or other encoder padding details, is iTunes successfully employing a DIFFERENT strategy than foobar to play these gapless? Does it try and do something fancy when the LAME headers are absent?

Ah, I see. This edit below seems to answer the above question as well. Sorry I missed that first time around. THANKS!

Quote from: greynol on
(*) To save you some reading, the discussion seems to indicate that iTunes will search for additional silence at the edges of mp3 tracks in the event that the tracks do not contain gapless information that is either tagged when encoded by iTunes or inside a Lame header.