No, that's something that has been talked about pretty much since the 1st Mk.1 shipped but it hasn't been scheduled for any specific release yet.

Rob

I don't think it would have made much (any) difference to sales. The feature list was already incredible compared with anything else in the market.

Rob

Hmm.. I think that feature might well be in there. As the release notes said, there is a LOT of stuff in emplode that isn't in the release notes at the moment. It's been completely rewritten from scratch.

Rob

I don't know how many the eStore have at the moment, but I have about 200 mounts in Cambridge awaiting wiring looms. The looms have been ordered and are due for delivery any day.

Rob

yum.

(O|||||O)

Surely the additional info screens and such are available in the menu structure...

Fly me to the moon...

Aux-In detects track transitions, and guesses at track numbers and
timecode?

or was it something else? I'm curious, what was it?

John

30 GB - Mk2a (Rio Car) - BLUE / RED

It was the Gapless playback.

Whenever I rip a continuous-track album, I always trim the files with GapKiller so that they sound right in WinAmp with the gapless output plug-in. I've gone to a lot of trouble with my collection to ensure this.

The xaudio engine in 1.0x always had a tiny pause between two songs. Just enough so that you could hear it if you were listening closely. So all the work I did with GapKiller was never realized on the car player.

I don't know if it was due to the work of the empeg guys, or if this is built into the new ARM engine, but now there is no pause of any kind between two tracks with 2.0.

So suddenly all of my collection plays gapless now. Well, at least as well as it can considering the source material and the trimming I had to do to the files. It sounds exactly like the gapless output plugin in WinAmp: 90 percent of my hand-trimmed track transitions are perfectly seamless. The remainder are so close that you don't notice it unless you're trying really hard.

I can listen to Dark Side of the Moon again.

___________
Tony Fabris

So we need the Rio remote for some of the new features

How does the Kenwood KCA-RC600 compare to the rio remote? I know it's supposed to do everything the kenwood credit card remote does, except for 1 button.

I hate the credit card remotes. We need a squishy-button style remote.

MP3 playback is now done using the ARM decoder. There should be little in
the way of audible difference.....

May I ask how it was decoded before and/or the difference?

WMA files are supported, apart from DRM encrypted files.

Pardon my ignorance but what is DRM encrypted?
Nevermind found it here if anyone else likes to know.

Thanks.

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

Edited by jwickis on 07/10/01 12:08 AM.

The decoder used in 1.0 was XAudio. The ARM decoder is more convenient for us under the hood in a number of ways, and is better optimised for the ARM processor (as you would expect). It also has fewer problems handling VBR files.

Rob

Yes, there are very few features which are entirely inaccessible without a Rio remote.

Rob

"The xaudio engine in 1.0x always had a tiny pause between two songs. Just enough so that you could hear it if you were listening closely. So all the work I did with GapKiller was never realized on the car player."


so that explains why your gap killer program didn't work when I tried it

32Gig MK2 In 2001 VW Golf TDI

This new ARM decoder, is that based on the IPP libraries? I was doing some research into some ARM development and I noticed Intel has a sample program that plays MP3's. I wasn't able to get it working on the Empeg (it compiled but it couldn't find the audio device.) I was just curious as to if the new decoder is based on this, and if so, if CPU consumption is reduced at all since they're Intel libraries.

-Tony
MkII #554

No, I believe it's based on Franhoffer and heavily optimised by ARM.

Rob

Hi all....

I remember some time ago the need for a one time database "conversation" for enabling the new features when upgrading to 2.x was mentioned. Is this still the case and if so is there a way to go back to 1.03 after this "conservation" has been done ?

Just thinking of loosing my large database due to bugs in 2.0 Beta 1? And BETAs are supposed to have bugs :-)))) I would like to avoid Re-uploading of 30 GB MP3s ...... 8-P

How long will this process of "upgrading" or "converting" the database take ?

Janosch

Tony,

If I'd want gapless playback with some mp3's I've got over here, then do I have to re-rip the cd's and convert then with lame with some special parameter or something (I seem to remember reading something about that a while ago), or do files that have been ripped and encoded with any encoder or player automatically work?

If I have to re-rip them it's not that bad : I'm talking about 10 cd's max here.

Riocar 10gig (for now) S/N : 10101747 red

It's Monday here in NZ, 12:20AM....hmmm but it ain't anywhere else....Dammit...

The database is compatible between v1.x and v2.x. There is no conversion process.

Except: the play_count/last_played data format has changed. There is no conversion process for this either -- the counts will be reset to zero.

You can go back and forth between v1.x and v2.x without any problems -- except for the dynamic data, as mentioned.

We are not aware of any catastrophic bugs in v2.x that would require you to reload all 30Gb.

-- roger

so that explains why your gap killer program didn't work when I tried it

My GapKiller program came with specific instructions on how to make it work with WinAmp. The web page included a link to the Gapless Playback plugin for WinAmp. Nowhere in the Gapkiller instructions did I say it would work with the empeg car player.

However, with version 2.0 of the empeg software, it now works just as well with the Winamp Gapless Playback plugin and the empeg car player.

___________
Tony Fabris

If I'd want gapless playback with some mp3's I've got over here, then do I have to re-rip the cd's and convert then with lame with some special parameter or something

I haven't tried that version of LAME yet. As I understand it, it's not ready for prime time yet. I'm interested in seeing how it performs.

In the meantime, there are two ways you can get gapless playback:

1) Rip your entire album as one huge song into one single MP3 file. Then use a splitter utility to cut up the MP3 at song boundaries. My GapKiller program includes just such a splitter utility.

2) Hand-trim frames off of the beginning and end of your existing mp3 files to remove the silent bits. This requires some trial-and-error to find the right number of frames to trim. This is what GapKiller does.

___________
Tony Fabris

The only thing this really changes now is: If you delete a track from a playlist, it does not disappear from the player. It's still there in the Soup views. If you want to get rid of the track completely, then delete it from the Soup view and it'll go away for good. Note that this feature now makes the "Unattached Items" folder obsolete. There is no longer an Unattached Items folder visible in Emplode. Everything that would have gone into Unattached items now appears in at least one or more Soup views.

Oh, wait. Is there a way to differentiate those songs only in the soup tree from those that are also listed in the playlists tree?
I would not want songs to remain on the player if I decided to remove them from the playlists. And it would sure be a hassle to search through those automatically generated tree to find all the songs from a certain compilation CD I just deleted. At least if I would have to remove them from each branch of that tree.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

I would not want songs to remain on the player if I decided to remove them from the playlists.

There has been some discussion among the alpha team regarding this. I do not know if the current beta does this, but future plans call for a dialog box to appear if you've just deleted a song from the last playlist.

Keep in mind that someday soon, when you can play directly from a soup view, you might not want it to work this way.

___________
Tony Fabris

Maybe if when you delete a song from a playlist a dialog box pops up that asks you if you also want to take it out of the soup?

32GB Mk. II in a WRX
Detroit, MI USA
www.PfeifferBeer.com

I don't remember reading that if wouldn't work on the empeg so I tried it :-). it didn't work with freeamp either I don't use winamp

I can't wait to try it with 2.0 player software

32Gig MK2 In 2001 VW Golf TDI

I don't use winamp (...) I can't wait to try it with 2.0 player software

One of the requirements of Gapkiller is that you need a gapless-playback program on the PC, Winamp is recommended because I supply the gapless playback plugin at my web site.

It's only useful if you can PREVIEW the trims, which is what gapkiller's primary purpose is. You have to do lots of trial-and-error work on each gap point, and if you don't have WinAmp with its gapless output plugin running, then you can't do that.

If you had to upload each trim to the empeg before listening to the gap, it would take approximately two hours to trim each song pair.

I recommend that you download Winamp, download the gapless-output plugin from my web site, and mess with it that way for a while. Once you've got the songs sounding right in WinAmp, then that's what they'll sound like on 2.0.


___________
Tony Fabris

Maybe if when you delete a song from a playlist a dialog box pops up that asks you if you also want to take it out of the soup?

I believe I just said that?


___________
Tony Fabris

I was using the newly added splitting program should I need to preview the tracks when using that ?

If I remember the instructions correctly with the splitting program I just needed to put in the start and ending times for each track. and there should be no space between the end of one track and the start of the next.

32Gig MK2 In 2001 VW Golf TDI

In reply to:

---

Gapless playback of properly-constructed MP3 files has been improved. Note
that this is dependent upon how the MP3s were created - most MP3 encoders
will add artificial silence to the beginning and end of each track as it
is being created. The car player will no longer insert its own gaps between
two consecutive tracks on playback.

---

This is great news! Now since it's a beta test I'll get to see if this is really implemented well. So here's what I will want answered, either by my own tests or from the people who might already know the answer.

Let's say I create a single, large MP3 file and split it into several pieces---for example, I encode an entire album and split the file into individual traks. Now suppose I play them in their original consecutive order on an empeg. Will it sound exactly as if the file was never split in the first place?

It is important to note that it is not sufficient to simply insure that the MP3 decoder does not insert any additional gaps between the MP3 files. An additional necessary condition is that the MP3 decoder's internal state is not reset between MP3 files, either. In other words, the computational section of the MP3 decoder must not even know where the file boundaries are. If the internal state of the MP3 decoder is reset between files, then a certain amount of information may be lost about the first few frames after a split.

As I have discussed in previous threads, this is the only practical way that I know of, for most if not all MP3 encoding engines, to insure true gapless playback: specifically, to encode an entire album as a single MP3 file, and then split the file along frame boundaries where the track boundaries are supposed to be.

Clearly, this is different from splitting the uncompressed .WAV file into pieces, and then encoding each one separately. One reason is somewhat obvious: if the length of a .WAV file is not an exact multiple of the MP3 frame size (1/75th of a second, I believe?) then silence will be inserted at the beginning or the end of the file to make it so. And yet, even careful, MP3-sensitive .WAV file splitting will not be enough: an MP3 encoder will often add additional silence to the beginning and/or the end of the file upon encoding despite this.

This is because each MP3 frame is not encoded independently of each other. So the sound produced during a particular MP3 frame depends upon the frames that surround it. Put another way, some of the information used to create the sound in a given MP3 frame is placed before or after that frame in the file. If this information would then run off the end of the file, blank space is inserted there to hold it.

So, the question is: will 2.00 pass this test---if not now, by the release? I am truly excited that it can!

Michael Grant
12GB Green
080000266

In reply to:

---

2) Hand-trim frames off of the beginning and end of your existing mp3 files to remove the silent bits. This requires some trial-and-error to find the right number of frames to trim. This is what GapKiller does.

---

Tony,

I believe that it's this second method that is the reason you may be getting only 90% effectiveness with your gapless playback instead of 100%. The problem is that these "silent" frames can actually contain information necessary to fully decode previous or following frames (I can't remember which). So trimming away the silent frames may cause you to lose some of audible information. The degree to which this matters will certainly depend on the source material. I've actually seen this audible information in otherwise silent MP3 frames by examining them with a hex editor.

As far as I know, your first technique is the only one that can be guaranteed to preserve all the musical content:

In reply to:

---

1) Rip your entire album as one huge song into one single MP3 file. Then use a splitter utility to cut up the MP3 at song boundaries. My GapKiller program includes just such a splitter utility.

---

But of course, I don't yet know if the new empeg decoder handles MP3 file boundaries in a fashion which will preserve this cross-file musical information.

Michael Grant
12GB Green
080000266