• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

FX-55 or Dual Core for transcoding?

R

Ronco

[H]ard|Gawd
2FA
Joined
Oct 6, 2005
Messages
1,308
Hello everyone.

I'm in the process of speccing a PC to handle some very heavy transcoding of FLAC into MP3. A simple question really, but which would be a better option, one of the upper-end Dual Cores or the FX-55? They're approximately the same price as far as I'm concerned. I'm not sure what software I'll be using, but LAME will probably be the MP3 encoding engine... so not the fastest I would imagine. Pros and cons of dual-core for this type of use? Are there better (Intel? Opteron?) ways of doing this? The PC won't be doing much else except to transcode and to transfer audio tracks to portables.

Would appreciate any answers. Thanks
 
You want to put a FX-55 or a dual core into a PC and use it only for transcoding audio?

I can't think of anything to say to that except my athlon 2000+ does just fine, you want to buy me a FX-55 and ill put it to good use, ill give you my 2000+ it's a palamino so you can even have enough heat to warrant watercooling :)
 
The intention is to get as fast an 'on-the-fly' transcode as is reasonably possible. And yes, I can easily justify building a PC specifically to transcode audio since I imagine I'd be doing a lot of it. I've started ripping my music in FLAC instead of MP3 since I'm transitioning to a home Lossless digital library. Putting Lossless on a portable isn't practical so I would like to transcode when I'm transferring music to a portable.


Regardless of whether it's done in batch overnight or on-demand, I want the transcode to be as fast as is possible within what I'm willing to spend. That spend is ~£1,300 for the box (with the exception of additional hard disks I might need if my Terastation keeps misbehaving), puts me around FX-55 range in terms of CPU price. I've tried running j.River on my FX-55 games machine and it's still some way off the mark of how fast I want it to be. So for now, I want the best FLAC > LAME bang for the buck in terms of the price range of the FX-55 + Asus A8N-SLI/Premium combo. The quieter it is, also the better it is. How much would encoding performance vary between the various options, and (obviously) which is the best choice are my questions.
 
With two cores you should be able to use the computer while transcoding the audio.

My vote goes for dual core.

EDIT: I have also seen some programs optimized for more than one core.
 
but if the machine is to be used only for transcoding audio go with the FX-55. If you want to do more than one transcode at a time go for the dual-core.
 
What type of workload are you talking about?

"The PC won't be doing much else except to transcode and to transfer audio tracks to portables."

10,000 cds worth of flac files?
How do the portables come into play?
Is this a dedicated machine? Or is this a one time job?

Depending on your purpose, you may even be best off building 3 Venice 3000+ level machines
 
I wasn't entirely sure of how the A64 dual cores worked. As I said, what I'm most interested in is as-near-as-real-time-as-possible transcoding. I'll be making use of for example the on-the-fly transcode facility of j.River Media Center when writing the FLAC library (transcoded to LAME-encoded MP3 files) on a portable. Try it out at jrmediacenter.com and you'll see what I mean. The thing is of course on a 'normal' machine, on-the-fly is something of a misnomer when trying to do this. On-the-make-a-cup-of-tea-for-even-an-album is more appropriate :p As I said, even on an FX-55 it's not exactly anywhere near what I would ideally want. If the FX is the best option given my box budget, it's what I'll go for. However I wanted someone with appropriate experience to tell me about the pros and cons of the alternatives.


Why don't I just stick FLACs on a portable, seeing as I have an iAudio X5 among others? I could tell you at least 5 different very good reasons, but suffice it to say a maximum of 320K and typically 256K MP3 is the only format I'm willing to use for portables. If the on-the-fly thing doesn't work out, I'll have to cobble together an hourly / half-day / etc compare/transcode of the library (keeping identical FLAC/MP3 libraries in sync) but either way, the transcoding needs to be quick. The box will be dedicated to managing my music library and syncing my portables, and will be built to supplement my existing media server, the third machine you see in my sig.
 
A fast single core processor is your best bet then, dual cores are very nice for everything, but if you are looking for raw speed in a single app like that, a FX-55 is going to do well. However, if the app takes advantage of multiple threads, then a dual core will be faster. I would say that it's most likely that the FX-55 will trump a dual core processor of lower speeds.

BTW, why are you using an Audigy2 ZS with the Orpheus :eek: :eek: :eek:
 
Makes sense I guess. I had hoped there was something better. I read some stuff (which I must admit I didn't really make the effort to understand) about Intel chips being faster for this type of use. Is that true?


The Orpheus alternates between gaming / casual listening use, so it and the Arcs are shared between various sources in the room with different inputs to the respective amps, and also through the use of a mixer. The PC sources are the 2ZS for games, and the Fireface for casual listening.
 
Well not that I would say dont buy a super fast machine.

But why the need to transcode on-the-fly. Why not just have sync of the flac to mp3 folder. Seriously do the whole lot of your music and then when you get new music update the mp3.

This is what I do with my small music collection of 4000 songs. I wrote a nice little perl script to transcode my flac to mp3. I just have 2 copies of my music, Hard disks are cheap. Speed is not an issue for me since it is only a one time affair. In fact my uberfast transcoding machine is a Athlon 900 Mhz machine with 512MB of RAM, the old Slot A CPUs ;). It takes about 4 days to transocde my collection but I only had to do that once, now to update when i get a new CD takes a little less than an hour. But to sync my iPod is as fast as it can possible be over firewire. Note my main workstation is not the Athlon 900 ;)
 
http://techreport.com/reviews/2005q2/athlon64-x2/index.x?pg=10

That will help answer your question.

Keep in mind that while they are using LAME MT (the multithreaded version of the LAME MP3 encoder), your software may not take advantage of multiple cores. So assuming it is not a multithreaded application, the FX-55 is the fastest processor for the job on that page, which includes the X2 and P4 XE 3.73. Looks like you pretty much have the best you can get right now.

By the way, awesome setups you have there in your sig, I'm very jealous :)
 
m1abram said:
Well not that I would say dont buy a super fast machine.

But why the need to transcode on-the-fly. Why not just have sync of the flac to mp3 folder. Seriously do the whole lot of your music and then when you get new music update the mp3.

This is what I do with my small music collection of 4000 songs. I wrote a nice little perl script to transcode my flac to mp3. I just have 2 copies of my music, Hard disks are cheap. Speed is not an issue for me since it is only a one time affair. In fact my uberfast transcoding machine is a Athlon 900 Mhz machine with 512MB of RAM, the old Slot A CPUs ;). It takes about 4 days to transocde my collection but I only had to do that once, now to update when i get a new CD takes a little less than an hour. But to sync my iPod is as fast as it can possible be over firewire. Note my main workstation is not the Athlon 900 ;)
Click to expand...


I posted this in another forum where all I got was replies like the above based on the apparent overkillness of what I was doing. I'm pretty impatient, so if a stack of CD's thuds on my doorstep as they do on a fairly regular basis, I'm not going to wait until next day to transfer them, and neither do I want to go through running multiple scripts and generally futzing if I can avoid it. Simply put, I'm all about getting results but with convenience.That's for example one of the reasons I like the iPod so much over all other players. I'm not sure if you've looked into situations like this with your dual-library set-up, but for example if I change the artist indication because I realised that a classical album I ripped 6 months ago was incorrectly tagged, it means the scripts will have to scan for changed details, not just changed files. That happens quite often as I'm browsing my library. By running one FLAC library and transcoding from that on-the-fly, I avoid any such complications. As I said, if it really doesn't work out I'll run two libraries. But my aim is to do it all from one library.


Talonz, thanks very much for that graph and letting me know of the existence of LAME MT. Very helpful, and exactly what I wanted. Since if I use j.River, it calls LAME as the encoder so I guess I can realise the benefits of dual processing. What I actually wanted is an effective transcode time of 4~5 seconds for the test data used in the shootout, not 20... but clearly that won't be around for a while in a £1,500 box :D I'll just check out things do work on the j.River side when calling LAME MT and if that's OK, go ahead with the Dual-Core 4800+. Many thanks.


Edit: Looks like j.River works when calling LAME MT. I think I'm all set :D
 
Well I do not futz around with scripts, it is pretty much a single run and forget setup I have once the CD is in FLAC format.

As for the second issue you state, I make sure ALL tag changes are done only in the FLAC files (i treat the mp3s as read-only). Then my one and only script I run when updates or new music needs to be added (its the same single script, i could even automate it even more by setting up a scan program with it). It handles updating the tags as well.

Transcoding on-the-fly will ALWAYS be slower in the long run than having two libaries. Sure you get the music SLIGHTLY faster to your iPod if you really have 10+ CDs arrive daily, but not by that much.

Also what software do you plan to handle the on-the-fly transcoding? The only one that works with the iPod on windows (sorry assuming your a windows user cause of your fear of scripts ;) ), is Anapod. While Anapod is a fine program it does lack support for iTunes wonderful Smart Playlists, it has morphlists but its functionality pails in comparision to iTunes. With dual libaries you do not restrict yourself to the software you can use.

HOWEVER to answer the Threads question I would go with a Dual Core system. If you write your own scripts it would be very easy to have them handle two cores very well. Very simple to have perl or something spawn two LAME processes.
 
There's been an interesting development. I've learned that j.River Media Center actually starts two instances of LAME when the transcode is invoked, and keeps two working as long as there are transcodes in the queue. I've tested that LAME MT is correctly called by j.River, which brings up another possibility... By opting for a dual-processor dual-core Opteron, I could in theory have two dual-threaded transcodes going at the same time. I'll have to think hard about raising my budget. Once again, it was really worth it coming to this forum. Thanks for the pointers Talonz.
 
I know you can have EAC launch multiple copies of LAME while ripping. So I would see no reason why any other program could not just launch multiple instances. The only advantage of using LAME MT over multiple instances of LAME is LAME MT will encode a single file FASTER where multiple instances of LAME make encoding multiple files faster. Course in theory if running two threads of LAME MT should encode 2 files as fast as two instances of LAME. Hope that made sense ;)
 
How fast are you able to rip the CDs to your harddrive?
Considering an Athlon64 3800+ does 20x realtime encoding, and a x2 4800 does it at 32x realtime, I would think that it outperforms the ripping CD-drive.
 
Esben said:
How fast are you able to rip the CDs to your harddrive?
Considering an Athlon64 3800+ does 20x realtime encoding, and a x2 4800 does it at 32x realtime, I would think that it outperforms the ripping CD-drive.
Click to expand...

The discussion is not really about ripping, but transcoding. So the CDROM drives performance is not really at play here.
 
I've decided to go out on a limb. Decided to build the system around two Opteron 270's. Spent an hour this morning poking around for parts, and put everything on (back)order. Hope it works out...
 
Ronco said:
I'm pretty impatient, so if a stack of CD's thuds on my doorstep as they do on a fairly regular basis, I'm not going to wait until next day to transfer them, and neither do I want to go through running multiple scripts and generally futzing if I can avoid it.
Click to expand...
m1abram said:
The discussion is not really about ripping, but transcoding. So the CDROM drives performance is not really at play here.
Click to expand...
Then how do you want the CD's to be transferred to a portable player, without ripping them?

Ronco: That sounds like a killer machine. I'm sure you will be happy with it.
 
As m1 said it has no bearing in this discussion. An accurate rip is even slower anyway. The discussion assumes the FLAC files exist.
 
You must log in or register to reply here.
Back
Top