MEPIS - MEPIS Talks - 2

read jerry's comment in the original thread... and my first thought was "Blast, and here I was thinking it was a pattern set from MEPIS Guides and MEPIS Lovers."

AMD 64bit lineup.

Socket 754
Athlon64
Sempron64
Turion64

Socket 939
Athlon64
Athlon64-FX
Athlon64-X2
Opteron 100 series

Socket 940
Athlon64-FX
Opteron

Socket F
Opteron

Socket AM2
Sempron64
Athlon64-X2
Athlon64-FX

Socket 754 - not supported
Sempron : Be careful, it is reported that some of the first socket 754 semprons are repackaged AthlonXp cores bolted onto the Single Channel memory controller used in the first Athlon64 processors. Other original Socket 754 Semprons are reported to have 64bit operation disabled at the hardware level, supposedly as the chips failed validation.

Intel:

Socket 775

Pentium4 Prescott with EM64T
PentiumD with EM64T
Core 2 desktop

Socket 479

Core 2 Mobile

********

Other words of note: Intel uses an emulation method to run x86-64 under 32bits on Intel Pentium4 Prescott. It is unknown if Conroe and Memron systems are still using Emulation, or if they are actually 64bit in hardware.

x86-64 was not a licensed technology.

First: according to one report, Intel reverse engineered it. http://www.extremetech.com/article2/0,3973,1561875,00.asp?kc=ETRSS02129TX1K0000532

Second : AMD gives the x86-64 specification away
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html

Tracked it down, x86-64 specification was given away back in 2000 : http://www.pcstats.com/releaseview.cfm?releaseID=326

Third : AMD runs a couple of different sites related to x86-64 development, this one might be of interest : http://www.x86-64.org/

Forth : Warren, I'm flat out amazed you haven't run into any problems running x86-64 on an Intel Platform.

And... yes, Intel went out of their way to reverse engineer a specification that was given away. Don't ask me why, I don't know.

Could someone start providing transcripts of these, I think some people would get more out of reading them than trying to listen to them.

Last week we asked for volunteers to do this. Warren and I do not have time to do a transcript. We barely have time to get the netcast together. I think a transcript team would be great thing for the community to do and post each of the transcripts on the wiki for all to see. Transcription is not the easiest of tasks if you are not experienced with it already.

-Matt

I think I'm being dissed here...

i'm just a home studio engineer so i'm no authority on this but i have a bunch of years in experience with recording and mixing sound and i hope my knowledge can help you in sharing your knowledge.

first let's go through the basic chain. Human voice, microphone, mixer, recorder.

1. as far as voices go, you both enunciate clearly so no problems there.

2. i'm not sure what kind of microphones are being used but even a cheap $20 mic is an improvement over PC mics.

3. when setting your mixer, check your levels and make sure you don't peak out (you don't want to go into the red).

4. even if you record at lower than normal levels, you can run it through any one of a number of audio effects processors to normalize the sound before you make the final save. I beleave Audacity should have everything you need to get a great recording.

the final and best advice i guess i can give is take a little time to experiment with sound levels and then the normalizing features of your recording software. you'll find a few minutes tweeking now will show a great improvement later.

Thanks to you both Warren and Matt for the Mepis Talks and for a software that ROCKS!

Oh yeah, as far as transcrips, i havn't done much research but there are speech recognition software out there. i use one to help with my book and it does a pretty good job.

here's one place i found that has a list of several different ones is you want to check it out.
http://tldp.org/HOWTO/Speech-Recognition-HOWTO/software.html

sincerely
Daryl

using SimplyMEPIS 6.5 RC3

if your into scifi, please check out my book site
www.myspace.com/starspan

Goth Mneph - do good

I think the main cause for the poor sound quality is that they are using the phone.

Suggestion: why not use skype or another voip solution out there and record the stream with audacity or the vsound wrapper? It would definitely improve the quality. And you couldn't run out of battery charge

Newbie or not Newbie, there's always a question

I have set up Audacity to record long duration services that can be reproduced at a reasonable speech quality by using a 16Hz sampling rate instead of 32Hz and setting Audacity to record in single channel mode using a 16 bit file format. My recordings are approx 70mb per hour, which are not suitable for public distribution such as a podcast due to their size, but they can be reduced quite a bit with a loss of quality. I tried using 8-bit, but these were not suitable for Audio CD reproduction, though it might be suitable for streaming media and/or downloading.

When using krec, try using 22050Hz, Mono and 16 bit. If the result is OK, try again using 44100Hz. In my experience, changing the sampling rate makes little difference to file size and most people can't hear the difference, but changing the bit rate makes a huge difference in file size and audio quality.

I might be totally wrong on this one because it could be your compressor settings, but ...... it does not appear that your recording is suffering from clipping through over-volume or too much gain, the telephone speaker output being fed directly into the mic (again, I might be wrong) or line input of your system, based on the quality of the reproduced sound, I am picking is distortion due to an over-voltage or over-supply at the line input and could be dramatically improved through the use of a simple circuit in-line to reduce the peaks, similar to those used in loud speaker enclosures consisting of a resistor and a capacitor.

If one of your uniden phones or bases has the option of speaker phone, strategically placing it for best pickup using a mic, turning speaker phone on and recording the audio with a microphone might produce a much cleaner sound if the first option is not suitable. Your voice could be natural and Matts could be picked up through the speaker, though this might take some trial an error to get it right.

Skype might be OK, unless you run into lag issues and delays caused by using an international server to relay what is essentially a local call.

Mike P

--------------------
Life may not be the party we thought, but while we're here, we may as well dance.
Break M$'s shackles from your feet and free yourself with Mepis

I hope I didn't offend anyone by asking for a transcript wiki.
There are more uses for a transcript than just the sound quality, it would be a good place to follow along with the broadcast. Also it would be a good place to discuss any questions or get some clarification on some things.
I do not think a transcript must come out at the same time as(or by the same people who deliver) the broadcast. I am sure that someone in our community should have the time to do this.

This is the processor I have

Sempron64

on 745

I bought the 64-Bit virsion

I once used Kubuntu 64-bit on it. when I bought it every one said that it was A 32-bit processor on a 64-bit socket. I was one of the first to get the 64-bit Sempron - yes it's 64-bit, though there is a 32 that they had before.

YES there is a 64-BIT sempron on 745.

Socket 754 - not supported
Sempron : Be careful, it is reported that some of the first socket 754 semprons are repackaged AthlonXp cores bolted onto the Single Channel memory controller used in the first Athlon64 processors. Other original Socket 754 Semprons are reported to have 64bit operation disabled at the hardware level, supposedly as the chips failed validation.

Well mine is not the first sempron at all.

Also the picture at the top right is an actual picture of me which I edited in gimp and gave my self green hair and an extra eye, just thought you would like to know.

Also by getting a new mic would improve the sound quality but really you need a higher bit rate also.

Even if you do get a very good mic it will still sound better but try a higher bit rate as well.

Try 94kbps not 64Kbps.

and I quote

The point I was making with the special note is that AMD did have a product line that didn't run in 64bits. The general rule of thumb with AMD is that if you have any socket AFTER Socket A, the processor is an x86-64 processor.

On the other hand, you have a large cross section of Processors on Intel's Socket 775 that are not compatible with x86-64. The advantage though, is that Intel's matrix for 64bit processors is decidedly smaller.

Next time guys can you talk about these questions.

Why does Mepis use KDE and not Gnome. I admit that I am a big KDE fan though just wondered.

Is Mepis really 98% Ununtu, considering we where based on debian previously but then we did not get called 99% debian by other silly users from other camps.

What about the silly comments on DistroWatch in the past and now, such as "ether PClinuxOS or Mepis will be gone by the end of the year". "Mepis needs to consider employing a graphics artist".

First of all let me say that I am enjoying these audio broadcasts. I am currently a Debian stable user and will be moving to Mepis 6.5 once it is final. So I am learning a bunch from the broadcasts and the websites.

In a former life I was a senior engineer for a telephone company and I believe that I can shed some light on the problems you are having with the audio quality.

If I understand correctly one of you is using a telephone to reach the recording site. All landline telephone calls are converted to a digital stream with 8 bit sampling at 8000 Hz (8kHz). Human speech has important frequency content from 300 to 3000 Hz, so this sampling process is entirely sufficiant for high quality voice.

Once the call is in the network a carrier may use compression to reduce their costs by carrying more conversations over the bandwidth they have. The more compression, the lower the costs, and the poorer the quality. The calls are decompressed at the other end of the call and converted back to analog for the last mile to the telephone set. All landline (non-cordless) residential telephones are analog.

Cell phones will use a very high compression rate and the analog to digital conversion and compression is done right in the phone itself. Once a cell phone call is in the network it may be decompressed and converted to another compression scheme compatible with a landline phone.

Depending on the compression rates, only so many compression and decompression cycles for a call can occur. With cell phones the initial compression rate is so high that any further recommpression will greatly affect speech quality.

The same thing happens for Voice over IP (VoIP), encoding and compression schemes will be used to reduce bandwidth requirments and deal with propagation delays through the network.

For the broadcast, you again encode and compress the broadcast into an MP3, so you again are reducing the quality of the speech.

The more times there is an analog to digital conversion (sampling) and encoding (bits) and compression, the greater the impact is on the quality of the speech.

So, the short of it is to minimize the number of conversions and compression cycles.

The best quality will happen when you are both together at the recording studio and only do a single conversion from live to MP3.

If a telephone must be used, do not use a cell phone or a cordless phone, use a landline. Do not use a speaker phone at either end, but use a proper telephone recording interface at the recording end to connect the phone to the sound card. Also avoid using a business phone on a PBX or Key system as they may also do an analog to digital conversion. Cordless phones may also do an analog to digital conversion and even compression.

If the call is a local call (not long distance) then there is a good chance no compression will be used by the carrier.

Do not record the MP3 in stereo, use mono. You will have to experiment with the encoding and compression used. A higher sampling rate, a greater number of bits, and less compression will give you a better quality if compression was used throughout any part of the telephone call. The downside is that the file is much larger.

If you can do the recording at the recording studio, sampling 8 bits at 8000 Hz will give you a good voice quality. Add MP3 compression to reduce the file size until you notice a degredation in quality.

Remember that there are those of us out here that are still stuck on dial up lines at low bit rates. I live with a 26,400 bps connection. Your second broadcast took me about 2.5 hours to download.

Thanks for the hard work on Mepis. I hope I could shed a little light on what is happening with the audio quality.

--
Darrell Bellerive
Amateur Radio Station VA7TO

Wow. Great to see another netcast so soon!

I created a page in the wiki where people can list what SimplyMepis64 will work on.
http://www.mepis.org/docs/en/index.php/Processors_supported_by_SimplyMepis64

Saist, please check it over. I don't know if it is necessary to know the motherboard too, so I left that out, but it can be inserted if needed.

As far as netcast catching clients, Amarok works but there are more full featured options out there such as BPConf aka KPodder
http://www.leonscape.co.uk/linux/bpconf/index.html
and IcePodder (the artist formerly known as CastPodder and found in junky form in the repos as ipodder)
http://icepodder.fryingoverajungle.net/

The-mother-of-all-linux-netcast-lists can be found here
http://lottalinuxlinks.com/forum/viewtopic.php?t=69

Amarok can get the files, but it is important not to try to play really low bitrate files on it that some podcasts are put out in. There is a problem with the xine sound engine it comes with in Mepis. Try Kaffeine or VLC media player instead.

I agree that 8kHz sampling would be sufficient, mono is fine, but 8 bits is not enough. 12 or 16 bits are needed at a minimum. Also, it is important to use the full dynamic range (without clipping). Only using half the dynamic range is like having half the bit depth.

Also, if you have an older computer with a PCI sound card instead of integrated sound, it will be less noisy. If the system you have can put out enough voltage and power, use Line In instead of Mic In. Most Mic Ins have a DC voltage on them for unpowered condenser mics (learned that on #mepis irc a while back...)

:::Ogg Vorbis:::

If you want to have more of a live show with people being able to ask questions on the fly. Also without having to purchase any additional software/hardware. You may want to try this: http://freeconferencing.liveoffice.com/free-conferencing.html
You can have up to 250 people conferenced on this line and also record then download the whole conference. Even if you don't use it for a live show, it may improve your audio problem. Another service is http://www.talkshoe.com. These are suggestions that I heard from Lockergnome from one of his YouTube posts. Hope it helps and thanks for all of your hard work!

Regards,
Wylis

Warren will be on next week's The Linux Link Tech Show

http://www.tllts.info

Nice.

Here's the transcript:
www.mepis.org/docs/en/index.php/MEPIS_Talks_2

Thanks ByCo!

--
Check out MEPIS Wiki: www.mepis.org/docs

3 cheers for ByCo!!

Man, you sure know how to listen and type at the same time....

Newbie or not Newbie, there's always a question

I tryed to type it slowly because not everyone can read fast.

LOL

--
Check out MEPIS Wiki: www.mepis.org/docs

I was going to ask about that, because the bandwidth did seem horribly limited, but that statement does nix a lot of suggestions that I had that wouldn't otherwise add to what Darrell already posted.

The only thing I can think of would be to digitally record each side of the convo, at each end of the connection, with some sort of sync arrangement; and sum the files together, afterwards, into a single file.


If nothing else, serving as a dire warning to others is not a bad thing to be.

::: smashing head against the desk :::

The scary thing is that kind of humor fits-in well around here.


If nothing else, serving as a dire warning to others is not a bad thing to be.

I've listened to several of the TWIT family of podcasts, and Leo's recommendations for good sound quality are:

1. Don't use the phone. Use Skype. A phone line bandwidth limitation is going to nuke your quality; no high frequencies (sibilants) will be left!
2. Get a decent quality mic. He recommends Plantronics for good and cheap, Rode for better and not so cheap.
3. Encode in mono at 64 or 32 kbps depending on what file size you can tolerate.

He uses a couple of configuration options to get the best Skype connection which I can't remember, but those are the most important.