new bug in v3.0.2.1 re MP3-to-CD

The new 3.0.2.1 is supposed to have fixed the problem wherein long MP3's (more than 14 minutes) are recorded in CD format with the 7:00 to 14:00 section looping after the 14:00 minute mark; yes, very weird!

Unfortunately, I can't test it on my MP3's because there appears to be a new MP3 bug. My setup is for podcasting the daily show from http://www.marketplace.org , downloading the 30 min MP3 and burning to a CD-RW (in Audio CD format) for listening-to in my car. But 3.0.2.1 refuses these MP3s? It will accept my music MP3's though. I tried playing with the file permissions but that didn't help.

According to Audacity (audio editor) the original MP3 is a mono track, 44.1 KHz. Maybe the new version can't handle mono?

Geez, that took a long time! The new 1.3.3-beta of Audacity wouldn't export MP3 anymore, so I had to reinstall 1.2.6. Then I couldn't figure-out how to convert the original mono to stereo. But now, finally, I think I've done it... and Nero 3.0.2.1 will accept the stereo version!

Is anyone from Nero seeing this post? Or, do I need to report it anew?...

(picking up the questions from the 3.0.2.1 announcement topic)

I tested with 2 files: one of ~14 minutes, the other of ~27 minutes. No problems in either case.

I tried one of the podcasts from marketplace.org, and also couldn't get Nero to accept it. If I dragged and dropped the file into the audio CD area, the action was ignored. If I right-clicked in the audio CD area, selected "Add files" and selected the file I got a pop up:

Nero Linux was unable to add /holdarea/temp/mktmorn.mp3 to the compilation:
/holdarea/temp/mktmorn.mp3 (invalid argument).

The "open with" choice for the file selects "audacious", so the file suffix appears OK.

The meta info shows 128 kbps bitrate, 7:41 length, 44,100 Hz sample rate, 2 channels.

I hit the same problem with a music MP3. One consistency is that the problematic MP3s are all Version MPEG 1.0, though I've other V1.0 MP3s that have worked OK.

More information and workaround.

I used mp3check to validate the file from marketplace.org (which Nero wouldn't accept) and got this:

$ mp3check -e mktmorn.mp3
mktmorn.mp3:
53857 bytes of junk before first frame header
valid id3 tag trailer v1.0 found

I then used mp3check to remove the junk:

$ mp3check --cut-junk-start mktmorn.mp3
mktmorn.mp3:
cut-junk-start: removing first 53857 bytes, retrying
cut-junk-start: no junk found

and Nero would then accept the file. I haven't burned it to CD, but suspect that it will work (it played OK in Nero). This approach also worked for the other file that Nero wouldn't accept.

wow, good detective work? So it wasn't the mono v stereo that fixed my test case yesterday, it was the fact that Audacious fixed some other 'junk' in the file.

So, why did all the previous versions accept these 'junk' MP3s while the new one does not?

The bug has been reproduced by our QA. It seems that the mp3 plugin is considering that the mp3 file coming from marketplace.org is somehow corrupted, and the decoding library rejects it.
BtW, I re-installed the 3.0.1.3 on one test PC, and the behaviour was the same.

After a quick look to it, it seems that our libraries that we use for decoding mp3s are not correctly handling the embedded cover inside mp3 files.
This is the reason while mp3check reports junk before the first frame.

Good news! The mp3 plugin is now fixed.
It will be included in the next version of Nero Linux 3.

Any chance this will be a sooner than later release?

Thanks mathf, a pleasure to see you here. The new version will be very welcomed.

There will be a minor update very soon containing the fix for this issue.

Great. BTW, Nero Linux is much more reliable for me than Nero 7 and above on windows.