Re:But what does it actually sound like???
on
AAC vs. OGG vs. MP3
·
· Score: 1
I decided to do my own evaluation between MP3, OGG Vorbis, and AAC. I don't have a Mac so I used my Windows machine and the PsyTEL MPEG-4 AAC Encoder. I used the latest LAME encoder for MP3 and the latest Ogg Vorbis command line tools.
I used INXS "Need you tonight" for my source WAV file since it has some good dynamics and great highs. I encoded each format as a 160K VBR file. Each file resulted in nearly the same size, about 3.5MB. I was not concerned with how long it took to encode or with spectrum analysis (though I did do analysis just to see the differences). I found the AAC file to be almost identical sounding to the WAV. The high frequencies were so clear and vivid (symbal crashes at the:58 second mark especially). The lows did not sound muddled. The OGG file sounded only slightly worse than AAC and only at higher frequencies. The MP3 sounded horrible in comparison to the others.
I've got an iPod and I love it. It's probably the best electronic device I've bought. I use it always (snowboarding, mountain biking, gym, home, car, getting car washed, jury duty, etc...). I was quite happy to hear of AAC support. I applied the 1.3 firmware but have not been able to get an AAC file on there (don't think Xplay supports that yet).
In a perfect world I'd love to see OGG Vorbis as the standard music file type. It's free to use by anyone and sounds amazing. Apple would make my day if they added support for it on the iPod. MP3 is horrible, unless you have tons of disk space to encode at the highest possible bitrate. Likely AAC will end up replacing MP3 eventually, and that is fine by me since it sounded best IMO, however I am worried about the effects of DRM. I feel that if I buy a CD, DVD-Audio or whatever, then I should be able to do whatever I want with it as long as I'm not giving it away to others (encode in any format, use on any of my devices, and make as many backup copies as I want!).
Working for a large ISP I see SPAM issues all the time. Most of them are filtered but some get through. Almost always they are from too many different source addresses. Had a dictionary attack just the other day but luckily the Subject lines all began with the same text, with the end of the line different for each message. Was able to just do a subject filter to discard the emails and return the SMTP servers to normal load.
I place the subject filters after the 'check_relay' section, example:
D{STEpat}Greenspan Drop
D{STEmsg}This message is SPAM
R${STEpat} $* $#discard
RRe: ${STEpat} $* $#discard
-or to give error message instead of discard-
R${STEpat} $* $#error $: 553 ${STEmsg}
RRe: ${STEpat} $* $#error $: 553 ${STEmsg}
You can put a much more interesting error message to return of course.;-)
Actually, your peak/off-peak hours are incorrect. I work for a cable ISP and I consider peak to be 4PM-2AM and off-peak 2AM-4PM.
The real problem is not with listening to Internet radio. The problem is with limited upstream bandwidth available. This is due to the way cable systems are laid out. There is a 6Mhz channel for downstream but only up to 3.2Mhz channel for upstream, and some ISPs still use 1.6Mhz. Combine that with lower modulation available on upstream (due to noise), result is upstream congestion. That can happen even if you have very few users on a combined network, the real problem is demographics and who decides to run servers all day.
All roadrunner services are supposed to be 2000kbps down and 384kbps up. If you're not getting that then either they have over subscribed your area or there are cable plant problems (noise and such) that are preventing clean packet transmission. Of course, if everyone in your town is getting the same slow speeds, then perhaps they did decrease the caps. Thats a dumb move though.
I agree with your comments. The only problem is that in a cable plant there is not enough bandwidth as it is, perhaps when DOCSIS 2.0 is out that will be a different story. For now, the only feasable option is to reduce the bandwidth caps to something even lower (yah I hear the bitchin). By doing so there is less ability for one or only a select few 'hogs' to take all the bandwidth which results in poor service for others. Reduce the caps and let the customer run whatever they want.
There are two problems though with potential subscriber servers. Open SMTP relays mainly. Too many people have absolutely NO CLUE about securing services. Open relays get ISPs in serious trouble. I am totaly for blocking that out on residential use. Another problem is open proxies for the same reasons. So I think there is some policing that has to be done since these connections are always on, and almost always at the same IP address. But I see nothing wrong with running web servers, or working from home, NAT, etc.
The problem is not the mail client itself. The problem is the secure ID. You have to enter a NEW code along with your password each time you check your email. Therefore the program can check, but a password prompt appears each time.
Was poking around the mirrors and noticed some dont have the 8.2 release just yet. But did notice that the checksums for the new release are the same as for the RC1 version. Wonder what thats all about.
This is already in the works.
- Video on Demand. Not hard to implement but pretty costly.
- Voice over IP. Already in some cities but less priority than multiple ISPs. This requires a more stable cable plant with very little noise (not an easy task).
- Multiple ISPs on the same cable. This is already rolling out in some cities and most will be completed this year.
I work for Road Runner, we dont care if you are NAT'ing. In fact its better cause it saves IP addresses. We just dont support it, meaning dont have any reps to troubleshoot that type of connection. Not sure why Comcast would take that route. If a customer wants to do that, then fine. They only get a set amount of bandwidth anyway.
Perhaps they want to charge for each IP address you would need by NOT using NAT.
Slashdot Mirror
I decided to do my own evaluation between MP3, OGG Vorbis, and AAC. I don't have a Mac so I used my Windows machine and the PsyTEL MPEG-4 AAC Encoder. I used the latest LAME encoder for MP3 and the latest Ogg Vorbis command line tools.
:58 second mark especially). The lows did not sound muddled. The OGG file sounded only slightly worse than AAC and only at higher frequencies. The MP3 sounded horrible in comparison to the others.
I used INXS "Need you tonight" for my source WAV file since it has some good dynamics and great highs. I encoded each format as a 160K VBR file. Each file resulted in nearly the same size, about 3.5MB. I was not concerned with how long it took to encode or with spectrum analysis (though I did do analysis just to see the differences). I found the AAC file to be almost identical sounding to the WAV. The high frequencies were so clear and vivid (symbal crashes at the
My Rankings:
1. WAV (of course)
2. AAC
3. OGG Vorbis
4. MP3
I've got an iPod and I love it. It's probably the best electronic device I've bought. I use it always (snowboarding, mountain biking, gym, home, car, getting car washed, jury duty, etc...). I was quite happy to hear of AAC support. I applied the 1.3 firmware but have not been able to get an AAC file on there (don't think Xplay supports that yet).
In a perfect world I'd love to see OGG Vorbis as the standard music file type. It's free to use by anyone and sounds amazing. Apple would make my day if they added support for it on the iPod. MP3 is horrible, unless you have tons of disk space to encode at the highest possible bitrate. Likely AAC will end up replacing MP3 eventually, and that is fine by me since it sounded best IMO, however I am worried about the effects of DRM. I feel that if I buy a CD, DVD-Audio or whatever, then I should be able to do whatever I want with it as long as I'm not giving it away to others (encode in any format, use on any of my devices, and make as many backup copies as I want!).
Working for a large ISP I see SPAM issues all the time. Most of them are filtered but some get through. Almost always they are from too many different source addresses. Had a dictionary attack just the other day but luckily the Subject lines all began with the same text, with the end of the line different for each message. Was able to just do a subject filter to discard the emails and return the SMTP servers to normal load.
;-)
I place the subject filters after the 'check_relay' section, example:
D{STEpat}Greenspan Drop
D{STEmsg}This message is SPAM
R${STEpat} $* $#discard
RRe: ${STEpat} $* $#discard
-or to give error message instead of discard-
R${STEpat} $* $#error $: 553 ${STEmsg}
RRe: ${STEpat} $* $#error $: 553 ${STEmsg}
You can put a much more interesting error message to return of course.
Actually, your peak/off-peak hours are incorrect. I work for a cable ISP and I consider peak to be 4PM-2AM and off-peak 2AM-4PM.
The real problem is not with listening to Internet radio. The problem is with limited upstream bandwidth available. This is due to the way cable systems are laid out. There is a 6Mhz channel for downstream but only up to 3.2Mhz channel for upstream, and some ISPs still use 1.6Mhz. Combine that with lower modulation available on upstream (due to noise), result is upstream congestion. That can happen even if you have very few users on a combined network, the real problem is demographics and who decides to run servers all day.
All roadrunner services are supposed to be 2000kbps down and 384kbps up. If you're not getting that then either they have over subscribed your area or there are cable plant problems (noise and such) that are preventing clean packet transmission. Of course, if everyone in your town is getting the same slow speeds, then perhaps they did decrease the caps. Thats a dumb move though.
I agree with your comments. The only problem is that in a cable plant there is not enough bandwidth as it is, perhaps when DOCSIS 2.0 is out that will be a different story. For now, the only feasable option is to reduce the bandwidth caps to something even lower (yah I hear the bitchin). By doing so there is less ability for one or only a select few 'hogs' to take all the bandwidth which results in poor service for others. Reduce the caps and let the customer run whatever they want. There are two problems though with potential subscriber servers. Open SMTP relays mainly. Too many people have absolutely NO CLUE about securing services. Open relays get ISPs in serious trouble. I am totaly for blocking that out on residential use. Another problem is open proxies for the same reasons. So I think there is some policing that has to be done since these connections are always on, and almost always at the same IP address. But I see nothing wrong with running web servers, or working from home, NAT, etc.
The problem is not the mail client itself. The problem is the secure ID. You have to enter a NEW code along with your password each time you check your email. Therefore the program can check, but a password prompt appears each time.
Was poking around the mirrors and noticed some dont have the 8.2 release just yet. But did notice that the checksums for the new release are the same as for the RC1 version. Wonder what thats all about.
This is already in the works.
- Video on Demand. Not hard to implement but pretty costly.
- Voice over IP. Already in some cities but less priority than multiple ISPs. This requires a more stable cable plant with very little noise (not an easy task).
- Multiple ISPs on the same cable. This is already rolling out in some cities and most will be completed this year.
I work for Road Runner, we dont care if you are NAT'ing. In fact its better cause it saves IP addresses. We just dont support it, meaning dont have any reps to troubleshoot that type of connection. Not sure why Comcast would take that route. If a customer wants to do that, then fine. They only get a set amount of bandwidth anyway.
Perhaps they want to charge for each IP address you would need by NOT using NAT.