I've got the Blue Man group ripped from the Audio CD, as well as 1 track from the Audio DVD. Ripped using CDparanoia, encoded with Lame 3.89ish. Plays like a charm under 1.03, and every other mp3 decoded I can find. Even the Rio Receiver plays it quite well.

2.0b3 doesn't seem to like these files at all.

I've put the DVD ripped file up on my website for empeg support, but it now appears that it wasn't just that file.

Symptoms appear as an intense crackling during bass hits, and generalized distortions.

Update:

mp3tool showed these files as having a bad vbr header.

I fixed the header, and re-uploaded. Music is fine now, including the DVD rip.

Why would the timecode header effect the music?

Now I've got to go write some more perl to download the files off the player, run mp3tool --repair on them, and then upload them back on. I'm sure that over 70% of my music is going to be like this, as most of them were encoded at the same time. What I don't understand is why it's effecting like this.

Greetings!

I am hoping there is something correctable. I have been noticing time code / length problems that did not seem to be there in 1.03. mp3trim listed them as having no errors. Is this player / decoder more sensitive to MP3 errors?

Paul G.
SN# 090000587 (96GB Smoke)
SN# 030103046 (10GB Blue - Emergency Spare)

I have been noticing time code / length problems that did not seem to be there in 1.03. mp3trim listed them as having no errors. Is this player / decoder more sensitive to MP3 errors?


I'd say it's very much more sensitive. I did NOT have problems with the length timecode... just the audio. And for that matter, I didn't have any problems on any other mp3 decoder.

I'd understand it if I pulled these from the net or something..... But I ripped them myself, and went over the encoding and tags very carefully before uploading... Obviously not carefully enough, given that mp3tool showed them being damaged.... but if the decoder is reacting to bad tags in the manner I noticed, I'd say it's certainly a bug, regardless if the file itself is slightly out of whack... I agree the file needs to be fixed... Which is exactly what I'm trying to figure out how to do easily, but I have to guess that the majority of the VBR files out there are going to have damaged headers, which play fine on other equipment.

Synergy,

If you would be willing to share that perl script, I think there are a lot of us here who are in the same boat. I haven't had any playback problems, but I have noticed that resuming after a pause will not restart from exactly the same place it stopped. As this only happens with VBR tunes, I suspect headers.

Actually, now that I think about it...

How about poritng mp3tool to the empeg? Then we can just kick it off one night and let it run.

"Wait, let's feed the mayonaisse to the tuna fish!"


-Zandr
Mk.I #0150 10GB
RioCar #010101243 10GB (96GB here I come...)

How about poritng mp3tool to the empeg? Then we can just kick it off one night and let it run.



I thought about this... but I'm not sure what it would do to the database... I'm certain that it does change the file about a bit.... Even though it's more trouble, I'd rather re-upload the files than muck with them on the player....

Unless someone KNOWS different????

I would like to run mp3tool on the drives of the empeg, if for no other reason than to pick up a number on how many are damaged...

I'll be sure to make any scripts I do available... But they will undoubtably be unixed....

Make sure to hang on to a copy of one of the "bad" files so that you can send it to the empeg folks.

The worst thing that should be happening with bad VBR headers is that your time indices for the song should be off. It shouldn't affect the audio output. I would definitely consider it a bug for the files to play with bad audio.

___________
Tony Fabris

Okay, I'm not sure if mp3tool will even work when run on an Empeg -- it tries to read the entire file at once into an internal buffer, the Empeg only has 16MB ram, and some mp3 files can be rather large.. I suppose if maybe swap was enabled to provide more virtual ram.

Anyway, if somebody there wants to rebuild mp3tool on an Empeg for use on the Empeg, email me and I'll loan out the source code (not open-source, for now). mlord@rtr.ca

Just send me back a binary for posting up on my web site.

Also, mp3tool does not yet understand the "Xscale" field of the Xing VBR header (latest version just leaves it alone).. can anyone explain what that field is for, and perhaps how to check for valid contents?

I just had this problem.

Interestingly, it has nothing to do with the time code. This is on a file with correct time code and correct VBR headers that has played fine on my unit in the past.

Also, Synergy sent me the "bad" BMG file that he was having trouble with, and it played fine on my player.

I think the act of re-uploading the file corrected some of the metadata related to the file and I think that's what fixed it.

In my case, the file was Paula Cole's "I Believe in Love". I know the file is fine, it's played fine for a long time in this player. I'm grabbing the file directly off of the player with EmpegTaxi, and I'm going to replace it in the player without changing it and see if it fixes the problem.

___________
Tony Fabris

Correction: The file wasn't even VBR, it was 128kbps fixed.

___________
Tony Fabris

Yup, that fixed it.

I grabbed the file off the player using EmpegTaxi, then I selected the file in Emplode, right-clicked on it, hit "replace tune", and selected the file I'd just downloaded.

It now plays fine in my player without any crackling.

The crackles were, I believe, clipping because it was playing too loud.

Okay, this is going into the bug database. I'm also going to mention it to the gentleman who was complaining of volume problems...

___________
Tony Fabris

Oddly, this problem did NOT happen on the other songs in the same album. All songs were uploaded at the same time, they have sequential FIDs, so if it was some sort of a database problem, I would think they would all have been affected.

THIS IS REALLY STRANGE.

Note that the audio problem was still present even after I fully power-cycled the player and also after a complete reinstall of 2.0b3 and a re-queueing of the song in question. So I know it wasn't a brief playback fluke or a caching issue.

___________
Tony Fabris

Hi,

Maybe Xscale is an old version of the scalefactor field?

Sean

I allready had that bug with my pink floyd tracks. 2 tracks of the album were completely garbled...
gonna replace and check metafid before and after...


Frank van Gestel

diff output :

5c5

< ctime=1003450718

---

> ctime=990109669

9c9

< mtime=1003450729

---

> mtime=990111666

15d14

< year=1999

I can't listen here. will see tomorrow if this solved problem, but the only apparent difference is the year tag ????

Frank van Gestel

Next time you get a distorted track, could you send us the *1 file? You should be able to work out which FID it is using emplode.

There is a not-yet-enabled feature which should be collecting minimum and peak level data but not actually doing anything with it. It does sound rather as though it might be doing something with it.

Rob

This is a case of new-functionality-escaped-before-it-was-supposed-to syndrome.

When the normaliser is finished it will probably be neat, but right now it would seem to have a few problems. I will write an essay for Toby explaining the difference between internal and release builds

The next release will have this problem fixed, one way or the other.

Rob

When the normaliser is finished it will probably be neat,

/me jumps up and down with excitement. Even I didn't know about this one.

___________
Tony Fabris

I've got two identical files on my empeg, with the only differences in the *0 file as explained before
The strange thing is that one of them is not playable; ie generates a hissing sound.
This is really strange...

Frank van Gestel

That data is stored in the dynamic data -- it's not available in the *1 file.


-- roger

Hey, cool! Don't drop normalizer (although it will, obviously, have to be configurable - we don't want different gain for, say, tracks from the same live album or movements of the same sonata).

OK, so I should try Tony's remedy and upload the tune again in order to reset those levels (I had similar problem - among others - described here). Is there a way to disable this half-bug-half-feature untill it is fully baked, or will we have to wait for the next beta?

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

although it will, obviously, have to be configurable - we don't want different gain for, say, tracks from the same live album or movements of the same sonata

You probably won't need to worry about that. Most CDs have each and every track normalized already. This normalizer would only be useful for those rare occasions when you have a non-normalized track.

___________
Tony Fabris

You probably won't need to worry about that. Most CDs have each and every track normalized already. This normalizer would only be useful for those rare occasions when you have a non-normalized track.

Another day I ripped a CD in which every track peaked at almost exactly 70%. I want things like that normalized (OK, so I did it in ripper/encoder, but I could have forgotten, as I did with some old tunes). What I don't want is that normalizer rise peak level of, say, a quiet movement of a symphony to the level of loud finale.

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

You could nuke all of your dynamic data (this includes EQ, tuner, playlists and bookmarks), with the following:

$ dd if=/dev/zero of=/dev/hda3

Make sure that you get this exactly right, or you might end up nuking your music. You can check that you've got the right partition by doing:

$ fdisk -l /dev/hda

The dynamic data partition is the one labelled as "OPUS"

This information comes without any warranty, either express or implied. Use at your own risk. Your home may be at risk if you do not keep up payments on a mortgage or other loan secured on it.



-- roger

Thanks, but I don't want to nuke my playlists and EQ

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

I am an idiot . Playlists are also kept statically in /drive[01]/fids and dynamic version will be rebuilt from there. I am going to crawl back under my rock .

OK, that said, can one backup and restore EQ setings etc by dd'ing from /dev/hda3 and back? Any chance to learn offsets and lengths of various interesting things there?

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

When I said playlists, what I actually meant was bookmarks, and the current programme. My bad.

And yes, you can save interesting things by dd'ing hda3 somewhere safe. I'll try and dig out the offsets at some point.


-- roger

Thanks! Backing up EQ settings was long on my personal wishlist.

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Can someone put this 'nuke' command up on the riocar.org website? I think it's useful, kinda like a factory reset. Of course, with the accompanied disclaimer!

­­______________
Edwin de Vaan

I will write an essay for Toby explaining the difference between internal and release builds

Shouldn't that be: Toby should write you an essay, and I would have thought stay back after school for at least one hour's detention?

Alternatively, he should write out 50 times: "I must not fiddle with the build flags before I am instructed to do so by the teacher". Hand them in at the staff room tomorrow morning before assembly, boy.

One of the few remaining Mk1 owners... #00015

I have had maybe 10 out of approx 3000 files which have done this. A reload of the exact same file from my PC fixes the problem. All I can think of is some kind of corruption in the initial transfer. Sometimes the effects are amazing - a version of Cowboy by Kid Rock sounding like it's played through a kazoo:)

I have had maybe 10 out of approx 3000 files which have done this. A reload of the exact same file from my PC fixes the problem. All I can think of is some kind of corruption in the initial transfer.

Did the problem manifest itself only on version 2.0b3 and not on 2.0b7?

If so, then it has nothing to do with corruption. The files were never damaged, it was only a non-working piece of code being applied to the files at playback time.

This was a known bug in 2.0b3 and it was fixed in 2.0b7.

If you are sure you saw this problem happening in 2.0b7 please let us know.