I don't know if I've put this one on the wish list before, but here goes...

I sometimes have the same song in several playlists. Let's say I wanted to delete one such song. As I understand it, the file itself does not get deleted unless I delete it from all the playlists. At that point, it's automatically deleted from the unit. (Am I right about that assumption? There's no indication in Emplode that you're deleting a file or just a playlist entry.)

So, if I really wanted to eradicate the file, I must find where it exists in each of the multiple playlists. A search feature would be nice in this respect, then I could delete all occurences at once from within the search results box.

Another use for a search feature might be to check and see whether a given song exists already, before I go to the trouble of uploading the same song twice if I'm unsure.

Comments?

Tony Fabris
Empeg #144

That sounds like some kind of undupe function. There is some third party palm pilot software that exists for similar reasons, to locate duplicates, inform you of where they are and ask you if you want to remove them.. etc.

Calvin

That sounds like some kind of undupe function.

Not exactly. Most of the time, I want there to be duplicate entries in different playlists. And the Empeg, by default, doesn't dupe the file if you put it into multiple playlists. So that's not the problem I'm trying to solve.

I'm saying: suppose I want to know where all occurences of a given song are? There's no way to search in Emplode. I have to find them by hand-scrolling through all the playlists.

A Search feature in Emplode would be useful for other things, too.

Tony Fabris
Empeg #144

I want there to be duplicate entries in different playlists

I can see that you'd want duplicate entries in playlists. One problem I can foresee is with my taste in music. I listen to a lot of 'Trance' and 'Techno' music and much of it is on compilation CDs. If I have a duplicate track (exactly the same name and artist) it would be great if 'something' other than me could determine this and just put a playlist link instead of another MP3.

J.

If I have a duplicate track (exactly the same name and artist) it would be great if 'something' other than me could determine this and just put a playlist link instead of another MP3.

Well, that's not exactly how it works, and there's a good reason for it (I'll get to that in a minute).

Right now, here's how it works: If you don't want the Empeg to have duplicate files, then simply don't upload the dupes to it in the first place. Upload one copy of the song and make your own links to it in the various playlists.

What I meant about duplicate entries is this: If you copy a song (one that's already been uploaded to the Empeg) to more than one playlist (within the Empeg), it won't make two copies of the song on the Empeg's hard disk. The second copy is just a link to the first file. This makes perfect sense, of course.

But if there's a song that already exists in the Empeg, and you have another copy of the song on your PC hard disk, and you drag it from the Windows Explorer and drop it onto Emplode, then Emplode will dutifully copy the song onto the Empeg for you again, because that's what you told it to do.

Emplode has no way of checking whether it's the same song. Even if it did, that wouldn't help your particular situation: Having the same piece published on two different compilation albums. Because your MP3 files from those two different albums would be slightly different (different amounts of silence between the tracks, possibly even different EQ/Volume/Compression, etc.).

If Emplode used just the track information alone to determine a dupe, it might remove dupes that aren't really dupes. For example, I have many songs with the same title/artist, but they are different performances of the song. For instance, one might be the original studio recording, the second might be a live concert recording, the third might be a remastered version of the song, and the fourth might be a remix or an extended mix. So that's the good reason behind the fact that it doesn't use either the tag data or the audio data for dupe checking.

My whole point for starting this thread wasn't to talk about Emplode's dupe checking ability, I just used that as one example as to how a Search feature might be useful in Emplode.

Tony Fabris
Empeg #144

I see your point ... I suppose I'll just have to be careful when I start ripping my 450 CDs! The best thing would be to run a Windows 'dupe' application and hope for the best.

Let the ripping begin!

f I have a duplicate track (exactly the same name and artist) it would be great if 'something' other than me could determine this and just put a playlist link instead of another

---

Most of my music collection is also techno/trance.. one problem I think you might run into is that there's frequently different mixes for different songs - it won't be seemless to have two nearly-identical songs in two different cd's if you just use one of the songs..
-mark

...proud to have one of the first Mark I units

Playing with MusicMatch last night - I've ripped 10 discs now (440 to go!). It's easy to sort by track name, so I can easily see tracks that are the same duration and ditch copies.

J.

Are you checking the quality of the RIP with something like WinAmp? I would suggest a little caution until you know how well your RIPper does it's work.

The reason I say this is that I also leapt in head first and ripped my entire collection in a couple of weekends, got the empeg, downloaded continuously -

- then discovered to my disgust that there were clicks and pops in the RIPped tracks, and that some tracks had obvious commpression artefacts through being RIPped at a fixed bitrate that was too low for the quality of reproduction I wanted on high-frequency content tracks. I had to go back and eventually ended up doing the whole lot from scratch, including all the effort of having to re-edit all the CDDB ID3 tag faults in emplode before downloading (this is the biggest effort of the whole thing, as is testified by many on this board - any backup utility should, in my book, save just the playlist structure and the tags).

This meant I had to go back and learn how to use the RIPper properly (Audio Catalyst), and learn what settings to use to make sure I got good ratios of compression and good quality without using up too much disk space. I have now got a "policy" whereby I choose what bitrate is appropriate according to the album.

I know you said you weren't too worried about sound (open top and all that) but you will notice it, it will become annoying, and if your sound source is already distorted before you crank up the volume to impress the women on the cruise, then you are not going to score on the sound quality/volume stakes...

then discovered to my disgust that there were clicks and pops in the RIPped tracks... This meant I had to go back and learn how to use the RIPper properly (Audio Catalyst)...

Interesting you should bring this up. I just yesterday bought AudioCatalyst. I found, to my dismay, that its default ripping mode is the least reliable. Even more to my dismay, I found that its reliable modes (the ones with sector synchronization) did not work on one of my computers and were dog-slow on another one.

The truth is that I knew its Audiograbber engine had these problems, but that was over a year ago when I first tried Audiograbber. I was hoping the ripper had improved, but it hasn't. In any case, what I bought AC for was the encoder engine, and I am VERY happy with that. At the two highest quality settings, the variable bit rate encoder sounds fantastic, and is still VERY fast at doing its job.

Fortunately, AC allows you to encode .WAV files already sitting on your hard disk, so I can use my existing dead-reliable ripper (WinDAC32) and use AC to encode.

Something that I should mention, though, is that on one of my computers, AC works fantastic at its default settings because it likes my CD-ROM drive. When you have the right hardware, it is a really good product and does the job well.

One thing I've noticed about bad rips... more often than clicks and pops, what I get is a much more minor glitch that manifests itself as sudden stereo-image shifting. For instance, a panned instrument will suddenly hop from the left channel to the right channel, or vice versa. Therefore, when checking the quality of the rip, it is necessary for me to use headphones and listen closely for it. Have you noticed this?

Anyway, the moral of the story, to anyone else reading, is...

Don't trust your ripper to make good rips at its default settings. Listen to your rips carefully and make sure there are no clicks, pops, or stereo image problems. If there are, alter your software to use its "sector synchronization" method of ripping. It will be slower, but it will give you more reliable rips.

and that some tracks had obvious commpression artefacts through being RIPped at a fixed bitrate that was too low for the quality of reproduction I wanted on high-frequency content tracks.

That's the one thing that impressed me about AudioCatalyst. When you use its VBR engine and turn on the "High Frequency" checkbox, it does a much better job of capturing cymbals and similar sounds. When setting it at the top two quality settings, the resulting files are very good, and not much bigger than a 128kbps fixed bitrate file.

Tony Fabris
Empeg #144

check and see whether a given song exists already, before I go to the trouble of uploading the same song twice if I'm unsure.

Tony, I believe there is a ready solution to prevent uploading twice (and spilling your valuable US$ 156/6GB disk space ) using the 'Unattached Playlist'. Though I haven't tried it myself yet.

I intend to move all tracks into the unattached playlist. The main playlist will be 'artist name', sub playlist 'album' with the tracks within the album playlist. As far as I know, anything in 'unattached' will not show up in any of the playlists in Emma, but I did notice that contents of unattached are included in the search results of the 'direct select' option (the one that shows play by year, artist, title, genre, etc). Thus my unattached list will hold all originals.

Custom playlists for will hold copies of the entries in 'unattached'. These will show up Emma's playlist selection menu as usual (BTW Have you noticed that Emma can quickly jump to entries starting with 'M' by pressing the corresponding keyboard numeric on the remote)?

Avoiding dupes is easy now. You'll only have to check unattached, which is by artist / album.

Getting rid of MP3s remains as difficult as it is now, and really needs a search function, or another emplode maintenance method. I'll expand on that later, when I've thought about it a bit more, but I donot find today's emplode method very intuitive.

Any dangers using 'unattached' as holder for all uploaded albums and songs, Mike?


Henno
# 00120 (6GB+18)

OK, read all that ;-) So, what you're both saying is that I should probably ditch MusicMatch and get AC? If I do ... what settings would you recommend as a first cut/ no empeg yet/ want to start the ball rolling/ lots of music per Gb. Not asking too much there I feel.

Also - has anyone done any bit-for-bit comparisons between AC and MultiMatch?

I've ripped the same track with MM at various settings (will listen to them this evening for quality comparisons):

VBR 50% ... 3.4Mb
VBR 75% ... 4.5Mb
VBR 96$ ... 5.5Mb
128 ... 3.3Mb
160 ... 4.1Mb

According to the MM blurb, anything over VBR 50% won't provide noticeable improvement.

So, what you're both saying is that I should probably ditch MusicMatch and get AC?

Oh no, not at all. I'm sure what you're using right now is fine. In fact, I didn't start using AC until yesterday. I like it, but I'm sure that MM is fine, too.

Your file size comparisons are a great way to go about checking the quality of your rips. Good thing to do. Choose the settings that you think are the best trade-off between quality and filesize. Then maybe do a little math to decide just how many gigs of space you'll need to store all 400+ albums.


According to the MM blurb, anything over VBR 50% won't provide noticeable improvement.

VBR is nice because it can increase the bitrate on frames that have a lot of high frequencies, then throttle back the bitrate on frames that don't need it. So in theory, if you compare a VBR file to a fixed bitrate file of the same size, you should be able to hear an improvement in the high frequencies (less swishy-ness to the cymbals on the VBR file).

But keep in mind that the "won't provide noticeable improvement" statement is probably based on the concept that your average listener can't distinguish the high-frequency artifacts that the audiophiles can. So listen carefully to your sample track comparisons and decide for yourself.

Tony Fabris
Empeg #144

Great. Absolutely great. I can't tell the difference between any of the damn files! Admittedly my Altec Lanseng speakers are probably not doing the MP3s justice, but I don't have a cable long enough to stretch from the PC to my Marantz setup, my DVD player won't read CDRs so I can't convert to WAVs and see that way ...

I suppose I could run a cable from the headphone output from the laptop into the preamp....

I think I'll leave what I have already as 128 and rip the remaining at VBR 70% or so which according to MusicMatch help is comparable to 160. Worst comes to the worst, it stinks, and I have to do it all again, right?!

J.

I can't tell the difference between any of the damn files!

Well, since your baseline item was a 128kbps file, all of them should be very high quality. For most of the music I listen to, 128kbps is fine, and I can't tell the difference from the source material when listening casually. In fact, I can only hear artifacts on certain songs at 128, and only when I'm listening closely. Most of the music, it's not a problem. Like I said, the artifacts are very subtle, and unless you know what to listen for, most folks don't notice them.

I suppose I could run a cable from the headphone output from the laptop into the preamp....

Actually, you'd do best to plug a really good pair of headphones directly into the output and listen really closely.

Although at this point, it sounds like 128kbps (or at least a VBR average that equals about 128kbps) is going to be just fine for you.

Tony Fabris
Empeg #144

So in theory, if you compare a VBR file to a fixed bitrate file of the same size, you should be able to hear an improvement in the high frequencies (less swishy-ness to the cymbals on the VBR file).

Our resident MPEG compression expert (John) isn't in today so I can't double check what I've written below - it is all IMHO :)

Surely the number of distinct frequencies is more important than specifically high frequencies? The reason crashing cymbals sound so bad at low bitrates is because they contain lots of different frequencies so the encoder has to throw some of them away. In this case VBR can increase the number of frequencies stored and thus improve the quality.

The worst thing for an MPEG audio encoder to have to encode is white noise because it contains a wide range of frequencies. This is noticeable at low bit rates with applause.



--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

The worst thing for an MPEG audio encoder to have to encode is white noise because it contains a wide range of frequencies. This is noticeable at low bit rates with applause.

You're right, of course. I think we're both saying the same thing in different ways. In most music, rarely do you find high frequency content that isn't white noise. Perhaps certain synthesizer filter sweeps could produce sounds that are both high frequency and made up of regular patterns. Such things would probably data-compress quite well. You also might find regular data patterns in guitar feedback or portions of the sound from ultra-high tuned percussion instruments like triangles. But for the most part, if there's high frequency content in a piece of music, it's from white-noise sources like cymbals, vocal sibilance, and applause (as you said).

Tony Fabris
Empeg #144

including all the effort of having to re-edit all the CDDB ID3 tag faults in emplode before downloading (this is the biggest effort of the whole thing, as is testified by many on this board - any backup utility should, in my book, save just the playlist structure and the tags).

---

I'm kinda surprised that people are using emplode for id3 tag info. Why not use a program such as mp3 tag studio to edit the tag information beforehand? I started doing the tag information with empeg, but it's just soo much easier to use the mp3 tag studio, and the changes are made to the original files - not just in the empeg database...
-mark


...proud to have one of the first Mark I units

OK, read all that ;-) So, what you're both saying is that I should probably ditch MusicMatch and get AC? If I do ... what settings would you recommend as a first cut/ no empeg yet/ want to start the ball rolling/ lots of music per Gb. Not asking too much there I feel.

---

I would recommend vbr normal setting for albums you dont' really care that much about, and the next setting up (vbr has 4-5 settings) which is normal/high for music you care about..
-mark


...proud to have one of the first Mark I units