It's commonly observed that oggs of lower bitrate compare to mp3 at higher bitrates.
Kind of. I thought this too, until I ran across a track that sounds like crap encoded with ogg at about 128kb/sec. Interestingly, it was mostly voice - sounded like a bad reverb had been applied when ogg'd at low bitrate. When using -q4 I could still hear artifacts; at -q6 it sounded great, but I had an ogg with about 200kb/sec of data rate. The same track also sounds great with lame average bit rate of 160kb/sec.
YMMV, but to state that ogg always sounds better than MP3, especially at half the bitrate, is absurd.
I like that your car has that ASST/CHRG indicator on your dashboard.
I expect we could save the equivalent of all the oil in the ANWR if all cars had instantaneous MPG indicators on the dashboard. I know for one I would be modifying how I drive to run that number UP, and I don't think I am alone.
If that saved just 1% the 20 MILLION barrels of oil per day (per here) that the U.S. burns...
Why has this not been done? Would it cost an extra $50 per car? I think that the gasoline savings would more than pay for that over the life of the vehicle.
IANAT, but it's a seriously lousy job. Turn-over average is two weeks (from my memory of a local telemarketing firm). Mostly they are college-aged looking for some well-paying temporary work. The stress levels are incredibly high, between the call quotas and the hostile people being called.
Here's what YOU can keep in mind, to avoid the need for any high-tech solution:
The people calling you have to be able to not take your comments personally, or else they will not last as a telemarketer. You are wasting your time trying to be cute. If they have a thin-skin, they will realize that it's not the job for them in short order, without your help.
You are doing them a FAVOR by saying "not interested" or "put me on your do-not-call list" and HANGING UP. They can then get on with their list and you can get on with your life. You can even be rude with a clear conscience since you are doing them a favor by terminating the call as soon as possible. You don't have to say anything at all; just hang up. My suppertimes got much easier once I realized that cold-calls don't have to be a source of stress for me.
Telemarketing isn't cheap, and the telemarketing firm doesn't want to call you if you aren't going to buy. There's a FREE(*) telemarketing opt-out list in the U.S. run by the Direct Marketing Association, and it works. Use the Google to find it; it's well worth your time if you don't want to be called by long-distance or credit-card companies at supper time.
Before you flame me, realize I am not apologizing for telemarketing. I wish I could make the entire concept disappear with a wave of my hand, but I can't; telemarketing is too profitable to just go away. "There's a sucker born every minute", after all.
(*)Well, last I checked it was free if you sent them a letter for the cost of a stamp, and $5 if you register on-line (to keep you from registering all your friends and family and the phone book presumably).
Via google ... search for credits. It is amazing how much this still applies.
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.
``This is an integrated, distributed, general-purpose workstation,'' began the magician, ``ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state of the art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?''
The master raised his eyebrows slightly. ``It is indeed amazing,'' he said.
``Corporate Headquarters has commanded,'' continued the magician, ``that everyone use this workstation as a platform for new programs. Do you agree to this?''
``Certainly,'' replied the master, ``I will have it transported to the data center immediately!'' And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, ``I cannot find the listing for my new program. Do you know where it might be?''
``Yes,'' replied the master, ``the listings are stacked on the platform in the data center.''
Yes, you are so right. 8GB on that particular machine. That's my entire point -- you just can't do that on a 32 bit platform (without segmentation schemes that for all I know don't exist).
more than 2GB address space for your programs? I've loaded 6GB of hash table data on a 64 bit platform, and that's peanuts compared to what people are doing with some current database servers. You just can't do that kind of work on a 32 bit platform.
never having to compile with -D_LARGE_FILES (or your compiler's equivalent) again!
I'm sure someone can come up with reason number four for you... Once you get used to 64 bits (like Tru64, or Linux on Alpha for example), it's difficult to go back.
I haven't had a credit card company or a long distance company (MCI was the worst) call me since I added my number to the DMA list.
Really, direct marketers that use traditional methods (real mail, telephone) don't want to waste money on people who will not buy from them - it saves them money to use the DMA opt-out lists by increasing response rate - at least that's the theory. e-mail is essentially free, so no marketer has an incentive to use this new list, but the telephone one really works due to the cost of telemarketing.
You can believe me or not; they don't call me anymore so I win whether you do or not:)
Since the card readers are so cheap, and the cards themselves actually have CPUs, can you imagine a Beowulf clust... Aw, nevermind.
Re:Sorry, dd chopped mp3 files do not always work.
on
Splitting Mp3's
·
· Score: 1
No, not to beat a dead horse, but if you do this you will get.mp3 files that simply will not play with some highly respected players. Try it yourself:
for i in 0 1 2 3 4 5 6 7 8 9; do
for j in 0 1 2 3 4 5 6 7 8 9; do
dd if=yourfav.mp3 skip=1${i}0${j}00 bs=1 count=30000 of=test${i}${j}.mp3 done done
for i in test*mp3; do mpg123 $i; done
I get 30 that mpg123 won't touch at all (returns failure code), and a few more that it attempts but makes a gawdawful screech. Xmms will play them all. Go figure.
Point is, I would not stand for that sort of failure rate from a web site I was in charge of, especially if I have no control over the player involved. Would you?
Sorry, dd chopped mp3 files do not always work.
on
Splitting Mp3's
·
· Score: 1
This does not always work. If everyone used great MP3 players like we do, this would be fine, but many are screwed up by leading garbage on the file.
For downloads where you don't know what will be playing your file, I'm afraid that you must clean up the front of the file first.
It is realy easy to make mpg123 report:
Illegal Audio-MPEG-Header 0x3818402e at offset 0x367. or something similar and play very annoying screeches after using dd to chop mp3 files.
headerless format
on
Splitting Mp3's
·
· Score: 4, Informative
Since MP3 is headerless, you should be able to just calculate where in the file you want to be based on the bitrate, and use 'dd' to cut out a snippet.
I've tried this and it sometimes works and sometimes doesn't depending on the player, since the start of your file snippet will have junk in it, but it seems to me that it would be an easy programming exercise to create a program that would lop off the leading junk until it finds the next valid MP3 frame.
I don't claim to know much about MP3 format, but it appears from a quick session with a hex editor that frames start with 0xfffb9200 - can anyone verify this? If so, you could hack out something in an hour that would be fast, scriptable and do exactly what you want.
For extra credit points, you could then use mp3info to add id3 tags so your file will look cool when playing in xmms or whatever.
The trick to winning over the people who don't call it art is to have them express their creativity through the same medium.
My then girlfriend and I had the same argument 12 years ago. I was the computer student; she was the artist who was of the opinion that "computer art is not art." She meant of the fine variety...
Anyway, she sat down one day at my computer with a drawing program and produced a very detailed sketch. It was far and away better than anything I could do, but I said "You're right, it's not art". She instantly saw how wrong she had been!
She is now a graphic artist professionally using computers in her work (in downtown Little Rock I might add, so the location doesn't have much to do with the problem).
For the last 10 or so years, anyone has been able to drop in a $300 box to condition the electrons in their stereo system so that they don't bump into each other. I remember reading about the Tice TPT clock in an audiophile magazine... Here's a review of one similar device: http://www.soundstage.com/revequip/quantum_life_sy mphony.htm
I particularly like how it takes a full 15 minutes before being 100% effective - them electrons must not move at the speed of light after all.
Truthfully, I've always wanted to market a device in a dark matte box with a single button and an LED that takes about 10 seconds to come to full brightness. It needs to weigh about 30 pounds. It will make your soundstage wider and your highs clearer. The magic, of course, is in the specially treated LED. I can sell you one for $10,000 due to the rigorous nature of conditioning the LED with my extra-harmonic stabalizer. Have I finally found my market?
Man yeah, Alpha servers run in Space Heater Emulation (tm) mode.
We have a Compaq GS140 cluster, that with all the disk spinning and 16 cpus humming draws 192 amps at 240V! I'd say Compaq is not worried about power consumption with their AlphaServer line.
I'd like to be able to afford the power to run one of these in my garage. I won't even abide the 80W required by an Athlon though and wouldn't consider an Alpha at home for this very reason.
I think it's somewhat better power-wise than IBM's equivalent offerings though, in which you could slow-cook a roast.
Will Bruce and company present the same sort of in-depth attack on their own AES candidate Twofish?
I dunno... ever since that mistake in the code for Blowfish in the April 1994 issue of DDJ, I've kinda wondered who actually ghost-writes his code. IIRC, 32 bit addition ignoring overflow is what was called for, and in the listing it ended up being 32 bit addition and a mod(32) or some such, which set most of the bits of the register back to 0. That couldn't have helped... Anyone else catch that? In another implementation I saw, it became mod(232) which is truly strange. I guess that came from this where 2^32 becomes simply 232 if your browser doesn't render the SUP tag.
Free and unpatented algorithms are great to have around though, and I expect to see blowfish/twofish products even after the AES winner is revealed.
I'd love to see an 8-way desktop motherboard powered by Crusoe chips; 6 or 7 running my apps and one or two running code morphing software. It would allow blistering-fast SMP code to run, and unlike all other SMP options to date it wouldn't run in Space Heater Emulation (tm) mode!
How many Transmeta chips could you put on a mainboard before taxing the standard 200W PC power supply?
Nope, I'm talking about Oracle hash joins. Try joining two tables of over a million rows, with a large answer set, like this:
create table baz as select foo.*, bar.* from foo, bar where foo.key = bar.key;
In Oracle, which is NOT the topic I realize, if you use an index with a query like this you are screwing yourself.
If you use a hash join (Oracle 8 && up), you will be blown away. of course you have to use the cost based optimizer and analyze your tables first so it has some data to work with, and drop your indexes . I don't mind if you don't believe me; I had been a DBA for years before I believed indexes could be anything but great, but I am a convert now!
There are other things indexes kill performance on, namely inserts and deletes to a table with indexes on columns other than the ones in your where clause. It's often better to drop your indexes, do the update, and recreate the index instead of waiting on Oracle and wondering why it is taking so darned long.
Did you test just one query, like select count(*) from large_table on an unloaded box, once with filesystem files, and once with raw partitions?
We did, with the data all nice and striped across controllers, and while we did NOT see the performance increase we expected with raw partitions, we saw something unexpected that causes us to use raw devices exclusively: CPU usage during the benchmark.
Raw partition benchmark CPU useage was a third of what the filesystem benchmark was, and just a table scan was consuming 60% of available CPU. We'll be doing more with the data than reading and discarding it like our benchmark. CPU usage on raw partitions was under 20% CPU utilization (give or take a few percent - it's been a couple of years now - hardware was a Digital Alpha 4100 with 4 533Mhz EV5? processors and 4 Mylex DAC960 RAID controllers and Oracle 8.0.5)
We presume that getting rid of the extra layer of filesytem buffering gets rid of the excess CPU usage. Since the box we are on is not I/O bound when doing real work, and as stated elsewhere in this discussion "there is always a bottleneck", we found that we could get more work done per unit of time on raw partitions than on filesystem files. This was after having turned down the kernel filesytem buffer cache since Oracle does its own caching and doing all the normal tuning one would expect on a fresh database.
Just another $0.02 on the raw/filesystem debate... I'll admit that filesystem files are easier for the fresh DBA, but once you've taken the plunge and discovered their quirks, raw devices are no harder to manage than filesystem files, save for the fact that you have a finite number of disk slices without an LVM, but most Unices come with those anyhow.
The original poster needs a backup mirror of a 30GB database, which is largish but I agree not large enough to make RAID-1 cost prohibitive, and the advantage of RAID-5 over RAID-1 is cost.
Most DBA books assume a smallish transaction oriented database, with advice like "use indexes to your tables to speed query times", which can be very bad advice in some situations.
Point is, there is no "rule" when it comes to databases, which must be tuned very differently depending on their size and the intended use.
Your Oracle on Linux will be faster if you change the default block size on ext2 to 4KB or use some other FS, and use 4KB db blocks in Oracle (depending on what you are doing of course - smaller for OLTP, larger for DSS). And add more disk controllers. If you are serious about it, check out Mylex's line of SCSI RAID controllers. And add more RAM. And add another CPU; preferably 4 of them running Oracle EE which has the parallel query option.
Then of course you will have spent more on your Oracle license than on your hardware, with Oracle's new per-CPU-MHz licensing racket.
Like most everyone else, you are assuming all database are OLTP systems. Data warehousing or data analysis on the other hand requires MASSIVE data transfer rates (mostly read activity), and Raid 5 with large stripe sizes and multiple arrays works really well for this type database. Most queries against the roughly 3TB database I currently work on run in several minutes passing somewhere under 100GB of data each, and if we had used OLTP tactics (indexes to join everything, small block size for low latency reads, etc) to tune the database, they would run in days or hours instead of minutes. Aggregate I/O rates on this monster can exceed 500MBytes/second.
As to the original question, can Linux handle a 30 GB database, my answer would be "Yes, but it will hurt". Ever try staging more than 2GB of data on ext2? Ever try moving more than 1GB of data on ext2 with less than a 4KB block size? It hurts!
Someone please tell me that I will be able to use large files painlessly on Linux sometime. Until then, run large databases on name brand UNIX servers with name brand UNIX. Linux on x86 is good at a lot of things, but a large database isn't one of them YET.
Slashdot Mirror
It's commonly observed that oggs of lower bitrate compare to mp3 at higher bitrates.
Kind of. I thought this too, until I ran across a track that sounds like crap encoded with ogg at about 128kb/sec. Interestingly, it was mostly voice - sounded like a bad reverb had been applied when ogg'd at low bitrate. When using -q4 I could still hear artifacts; at -q6 it sounded great, but I had an ogg with about 200kb/sec of data rate. The same track also sounds great with lame average bit rate of 160kb/sec.
YMMV, but to state that ogg always sounds better than MP3, especially at half the bitrate, is absurd.
I like that your car has that ASST/CHRG indicator on your dashboard.
I expect we could save the equivalent of all the oil in the ANWR if all cars had instantaneous MPG indicators on the dashboard. I know for one I would be modifying how I drive to run that number UP, and I don't think I am alone.
If that saved just 1% the 20 MILLION barrels of oil per day (per here) that the U.S. burns...
Why has this not been done? Would it cost an extra $50 per car? I think that the gasoline savings would more than pay for that over the life of the vehicle.
Here's what YOU can keep in mind, to avoid the need for any high-tech solution:
Before you flame me, realize I am not apologizing for telemarketing. I wish I could make the entire concept disappear with a wave of my hand, but I can't; telemarketing is too profitable to just go away. "There's a sucker born every minute", after all.
(*)Well, last I checked it was free if you sent them a letter for the cost of a stamp, and $5 if you register on-line (to keep you from registering all your friends and family and the phone book presumably).
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.
``This is an integrated, distributed, general-purpose workstation,'' began the magician, ``ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state of the art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?''
The master raised his eyebrows slightly. ``It is indeed amazing,'' he said.
``Corporate Headquarters has commanded,'' continued the magician, ``that everyone use this workstation as a platform for new programs. Do you agree to this?''
``Certainly,'' replied the master, ``I will have it transported to the data center immediately!'' And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, ``I cannot find the listing for my new program. Do you know where it might be?''
``Yes,'' replied the master, ``the listings are stacked on the platform in the data center.''
Yes, you are so right. 8GB on that particular machine. That's my entire point -- you just can't do that on a 32 bit platform (without segmentation schemes that for all I know don't exist).
- more than 2GB address space for your programs? I've loaded 6GB of hash table data on a 64 bit platform, and that's peanuts compared to what people are doing with some current database servers. You just can't do that kind of work on a 32 bit platform.
- never having to compile with -D_LARGE_FILES (or your compiler's equivalent) again!
- avoiding the 2038 problem completely!
I'm sure someone can come up with reason number four for you... Once you get used to 64 bits (like Tru64, or Linux on Alpha for example), it's difficult to go back.I haven't had a credit card company or a long distance company (MCI was the worst) call me since I added my number to the DMA list.
Really, direct marketers that use traditional methods (real mail, telephone) don't want to waste money on people who will not buy from them - it saves them money to use the DMA opt-out lists by increasing response rate - at least that's the theory. e-mail is essentially free, so no marketer has an incentive to use this new list, but the telephone one really works due to the cost of telemarketing.
You can believe me or not; they don't call me anymore so I win whether you do or not :)
and sys/change_on_install...
and anyone who typed "oratclsh" followed by "exec id" and their eyeballs bugged out when they discovered they had h4xD r00t...
seriously, check your database and make sure oratclsh isn't setuid, and the administrative passwords aren't their defaults.
Lemme guess - you're over 30, right?
I'm glad *some*body said that...
Since the card readers are so cheap, and the cards themselves actually have CPUs, can you imagine a Beowulf clust... Aw, nevermind.
for i in 0 1 2 3 4 5 6 7 8 9; do
for j in 0 1 2 3 4 5 6 7 8 9; do
dd if=yourfav.mp3 skip=1${i}0${j}00 bs=1 count=30000 of=test${i}${j}.mp3
done
done
for i in test*mp3; do mpg123 $i; done
I get 30 that mpg123 won't touch at all (returns failure code), and a few more that it attempts but makes a gawdawful screech. Xmms will play them all. Go figure.
Point is, I would not stand for that sort of failure rate from a web site I was in charge of, especially if I have no control over the player involved. Would you?
For downloads where you don't know what will be playing your file, I'm afraid that you must clean up the front of the file first.
It is realy easy to make mpg123 report: Illegal Audio-MPEG-Header 0x3818402e at offset 0x367. or something similar and play very annoying screeches after using dd to chop mp3 files.
I've tried this and it sometimes works and sometimes doesn't depending on the player, since the start of your file snippet will have junk in it, but it seems to me that it would be an easy programming exercise to create a program that would lop off the leading junk until it finds the next valid MP3 frame.
I don't claim to know much about MP3 format, but it appears from a quick session with a hex editor that frames start with 0xfffb9200 - can anyone verify this? If so, you could hack out something in an hour that would be fast, scriptable and do exactly what you want.
For extra credit points, you could then use mp3info to add id3 tags so your file will look cool when playing in xmms or whatever.
The trick to winning over the people who don't call it art is to have them express their creativity through the same medium.
My then girlfriend and I had the same argument 12 years ago. I was the computer student; she was the artist who was of the opinion that "computer art is not art." She meant of the fine variety...
Anyway, she sat down one day at my computer with a drawing program and produced a very detailed sketch. It was far and away better than anything I could do, but I said "You're right, it's not art". She instantly saw how wrong she had been!
She is now a graphic artist professionally using computers in her work (in downtown Little Rock I might add, so the location doesn't have much to do with the problem).
I particularly like how it takes a full 15 minutes before being 100% effective - them electrons must not move at the speed of light after all.
Truthfully, I've always wanted to market a device in a dark matte box with a single button and an LED that takes about 10 seconds to come to full brightness. It needs to weigh about 30 pounds. It will make your soundstage wider and your highs clearer. The magic, of course, is in the specially treated LED. I can sell you one for $10,000 due to the rigorous nature of conditioning the LED with my extra-harmonic stabalizer. Have I finally found my market?
I'd like to be able to afford the power to run one of these in my garage. I won't even abide the 80W required by an Athlon though and wouldn't consider an Alpha at home for this very reason.
I think it's somewhat better power-wise than IBM's equivalent offerings though, in which you could slow-cook a roast.
I dunno... ever since that mistake in the code for Blowfish in the April 1994 issue of DDJ, I've kinda wondered who actually ghost-writes his code. IIRC, 32 bit addition ignoring overflow is what was called for, and in the listing it ended up being 32 bit addition and a mod(32) or some such, which set most of the bits of the register back to 0. That couldn't have helped... Anyone else catch that? In another implementation I saw, it became mod(232) which is truly strange. I guess that came from this where 2^32 becomes simply 232 if your browser doesn't render the SUP tag.
Free and unpatented algorithms are great to have around though, and I expect to see blowfish/twofish products even after the AES winner is revealed.
How many Transmeta chips could you put on a mainboard before taxing the standard 200W PC power supply?
How about it Transmeta? Please?
Try joining two tables of over a million rows, with a large answer set, like this:
create table baz as select foo.*, bar.* from
foo, bar where foo.key = bar.key;
In Oracle, which is NOT the topic I realize, if you use an index with a query like this you are screwing yourself.
If you use a hash join (Oracle 8 && up), you will be blown away. of course you have to use the cost based optimizer and analyze your tables first so it has some data to work with, and drop your indexes . I don't mind if you don't believe me; I had been a DBA for years before I believed indexes could be anything but great, but I am a convert now!
There are other things indexes kill performance on, namely inserts and deletes to a table with indexes on columns other than the ones in your where clause. It's often better to drop your indexes, do the update, and recreate the index instead of waiting on Oracle and wondering why it is taking so darned long.
TIA
We did, with the data all nice and striped across controllers, and while we did NOT see the performance increase we expected with raw partitions, we saw something unexpected that causes us to use raw devices exclusively: CPU usage during the benchmark.
Raw partition benchmark CPU useage was a third of what the filesystem benchmark was, and just a table scan was consuming 60% of available CPU. We'll be doing more with the data than reading and discarding it like our benchmark. CPU usage on raw partitions was under 20% CPU utilization (give or take a few percent - it's been a couple of years now - hardware was a Digital Alpha 4100 with 4 533Mhz EV5? processors and 4 Mylex DAC960 RAID controllers and Oracle 8.0.5)
We presume that getting rid of the extra layer of filesytem buffering gets rid of the excess CPU usage. Since the box we are on is not I/O bound when doing real work, and as stated elsewhere in this discussion "there is always a bottleneck", we found that we could get more work done per unit of time on raw partitions than on filesystem files. This was after having turned down the kernel filesytem buffer cache since Oracle does its own caching and doing all the normal tuning one would expect on a fresh database.
Just another $0.02 on the raw/filesystem debate... I'll admit that filesystem files are easier for the fresh DBA, but once you've taken the plunge and discovered their quirks, raw devices are no harder to manage than filesystem files, save for the fact that you have a finite number of disk slices without an LVM, but most Unices come with those anyhow.
Most DBA books assume a smallish transaction oriented database, with advice like "use indexes to your tables to speed query times", which can be very bad advice in some situations.
Point is, there is no "rule" when it comes to databases, which must be tuned very differently depending on their size and the intended use.
OK, there is ONE rule - test your backups!
And add more disk controllers. If you are serious about it, check out Mylex's line of SCSI RAID controllers.
And add more RAM.
And add another CPU; preferably 4 of them running Oracle EE which has the parallel query option.
Then of course you will have spent more on your Oracle license than on your hardware, with Oracle's new per-CPU-MHz licensing racket.
Like most everyone else, you are assuming all database are OLTP systems. Data warehousing or data analysis on the other hand requires MASSIVE data transfer rates (mostly read activity), and Raid 5 with large stripe sizes and multiple arrays works really well for this type database. Most queries against the roughly 3TB database I currently work on run in several minutes passing somewhere under 100GB of data each, and if we had used OLTP tactics (indexes to join everything, small block size for low latency reads, etc) to tune the database, they would run in days or hours instead of minutes. Aggregate I/O rates on this monster can exceed 500MBytes/second.
As to the original question, can Linux handle a 30 GB database, my answer would be "Yes, but it will hurt". Ever try staging more than 2GB of data on ext2? Ever try moving more than 1GB of data on ext2 with less than a 4KB block size? It hurts!
Someone please tell me that I will be able to use large files painlessly on Linux sometime. Until then, run large databases on name brand UNIX servers with name brand UNIX. Linux on x86 is good at a lot of things, but a large database isn't one of them YET.
SQL> select sum(bytes) from dba_data_files;
SUM(BYTES)
----------
2.9003E+12
And every byte is on RAID 5.