copying a mp3 file

help me...i am copying a mp3 file....but when i run the code the copied file is having larger size than the original mp3 file.....here is the code

Code:

---

#include<stdio.h>
#include<stdlib.h>
int main()
{
   
    FILE *fs,*ft;
   
    unsigned char ch;
   
    fs=fopen("17.mp3","rb");
    if(fs==NULL)
    {
                puts("cannot open source file");
                exit(1);
    }
    ft=fopen("16.mp3","wb");
    if(ft==NULL)
    {
                puts("cannot open target file");
                fclose(fs);
                exit(2);
    }
    while(1)
    {
            ch=fgetc(fs);
            if(ch==EOF)
            break;
            else
            fputc(ch,ft);
    }
    fclose(fs);
    fclose(ft);
    return(0);
}

---

ch should be an int, if you want to compare it with EOF successfully.

thanks salem.....it is working by taking ch as int
thanks again

Code:

---

#include<stdio.h>
#include<stdlib.h>
int main()
{
    FILE *fs,*ft;
    unsigned int size;
    unsigned char* buffer;
       
    fs=fopen("17.mp3","rb");
    if(fs==NULL)
    {
                puts("cannot open source file");
                exit(1);
    }
    ft=fopen("16.mp3","wb");
    if(ft==NULL)
    {
                puts("cannot open target file");
                fclose(fs);
                exit(2);
    }
   
    fseek(fs,0,SEEK_END);  // get file size
    size = ftell(fs);
    fseek(fs,0,SEEK_SET);

    buffer = malloc(size);  // allocate buffer space
 
    fread(buffer,size,1,fs);  // copy the file
    fwrite(buffer,size,1,ft);

    free(buffer);
    fclose(fs);
    fclose(ft);
    return(0);
}

---

Is it worth pointing out the flaws in CommonTater's approach?

Maybe tomorrow, lets see if CommonTater can make a better job.
Or perhaps even spot why the concept is flawed to begin with.

Quote:

---

Originally Posted by Salem

Is it worth pointing out the flaws in CommonTater's approach?

Maybe tomorrow, lets see if CommonTater can make a better job.
Or perhaps even spot why the concept is flawed to begin with.

---

Oh go ahead... you know you want to... Yes I forgot to free the buffer.... what else?

Quote:

---

Originally Posted by CommonTater

Oh go ahead... you know you want to... Yes I forgot to free the buffer.... what else?

---

Think BIG.

Quote:

---

Originally Posted by MWAAAHAAA

Think BIG.

---

What? MP3 files are virtually always under 100megs, most are under 10 ... that should be no problem unless you're on a DOS box...

I've malloced gigabyte size buffers many times with no problems...

O_o

Well, as long as we are posting alternative source...

Soma

Code:

---

#include <fstream>

int main()
{
    using namespace std;
    ifstream in("17.mp3", ios::in | ios::binary);
    ofstream out("16.mp3", ios::out | ios::binary);
    out << in.rdbuf();
    return(0);
}

---

Quote:

---

Originally Posted by phantomotap

O_o

Well, as long as we are posting alternative source...

Soma

Code:

---

#include <fstream>

int main()
{
    using namespace std;
    ifstream in("17.mp3", ios::in | ios::binary);
    ofstream out("16.mp3", ios::out | ios::binary);
    out << in.rdbuf();
    return(0);
}

---

---

Except that this is the C programming forum :)

That being the reason that is was a joke... see the smiley?

Soma

Quote:

---

Originally Posted by phantomotap

O_o

Well, as long as we are posting alternative source...

Soma

Code:

---

#include <fstream>

int main()
{
    using namespace std;
    ifstream in("17.mp3", ios::in | ios::binary);
    ofstream out("16.mp3", ios::out | ios::binary);
    out << in.rdbuf();
    return(0);
}

---

---

C forum says hello!

I was late...

Quote:

---

Originally Posted by phantomotap

That being the reason that is was a joke... see the smiley?

Soma

---

I can't, where is this???

Quote:

---

Originally Posted by phantomotap

That being the reason that is was a joke... see the smiley?

Soma

---

Nah, I think you couldn't find the delete button, so you're trying to save face by putting in an edit.

Quote:

---

Nah, I think you couldn't find the delete button, so you're trying to save face by putting in an edit.

---

Along that path lies boredom.

Soma

Quote:

---

Originally Posted by MWAAAHAAA

Nah, I think you couldn't find the delete button, so you're trying to save face by putting in an edit.

---

And people wonder why I have him on my ignore list...

hey guys.....i want some more help from you....i justwant to calculate the size of 17.mp3 in mb or kb......so what will i do ...count every int then calculate or there is an another way out.......

Quote:

---

Originally Posted by CommonTater

And people wonder why I have him on my ignore list...

---

And I'm such a likable fellow...

Quote:

---

Originally Posted by shubham

hey guys.....i want some more help from you....i justwant to calculate the size of 17.mp3 in mb or kb......so what will i do ...count every int then calculate or there is an another way out.......

---

Have a look at CommonTater's first post for a possible approach.

Quote:

---

Originally Posted by shubham

hey guys.....i want some more help from you....i justwant to calculate the size of 17.mp3 in mb or kb......so what will i do ...count every int then calculate or there is an another way out.......

---

Take a look at the code sample I posted... there's a very easy way to do it, in there.

Once you have the file size divide by 1024 for Kilobytes or 1048576 for Megs.

> I've malloced gigabyte size buffers many times with no problems
If you wanted this data in memory for a long time, then that would be fine.

But copying a 1GB file by allocating one large block of memory is basically a big waste of resources (and possibly even slower than you imagine).

For one thing, few operating systems will commit 1GB of REAL memory to a process which has only written to each page only once. Which means a large chunk of that memory you just loaded with file data is going straight back out to the swap file.

Then it comes back in from the swap file and out to the place where you wanted to save it.

It's also prone to random failure. One day you might be able to allocate enough space for a particular file. But maybe tomorrow, there is an extra process on the OS, or the file is just a little bit larger, and your attempt to allocate one stupidly large buffer returns NULL instead.
What's your error message to the user at this point?
"Sorry, unable to copy file due to ..."

Try this

Code:

---

unsigned char buf[BUFSIZ];
size_t n;
while ( (n=fread(buf, 1, sizeof(buf), in ) > 0 ) {
  size_t r = fwrite( buf, 1, n, out );
  if ( r != n ) {
    // some error message, probably no space left
    // use ferror
    break;
  }
}

---

No malloc/free issues, no swap file thrashing, works for files of any size.

And don't play that "It's only a small MP3 file" crap, because you know some doofus will just look at that code and think "Hey, it worked for MP3, what about AVI files?".

I agree with salem, reading the whole file does not always make faster.

Quote:

---

Originally Posted by Salem

> I've malloced gigabyte size buffers many times with no problems
If you wanted this data in memory for a long time, then that would be fine.

But copying a 1GB file by allocating one large block of memory is basically a big waste of resources (and possibly even slower than you imagine).

For one thing, few operating systems will commit 1GB of REAL memory to a process which has only written to each page only once. Which means a large chunk of that memory you just loaded with file data is going straight back out to the swap file.

Then it comes back in from the swap file and out to the place where you wanted to save it.

It's also prone to random failure. One day you might be able to allocate enough space for a particular file. But maybe tomorrow, there is an extra process on the OS, or the file is just a little bit larger, and your attempt to allocate one stupidly large buffer returns NULL instead.
What's your error message to the user at this point?
"Sorry, unable to copy file due to ..."

Try this

Code:

---

unsigned char buf[BUFSIZ];
size_t n;
while ( (n=fread(buf, 1, sizeof(buf), in ) > 0 ) {
  size_t r = fwrite( buf, 1, n, out );
  if ( r != n ) {
    // some error message, probably no space left
    // use ferror
    break;
  }
}

---

No malloc/free issues, no swap file thrashing, works for files of any size.

And don't play that "It's only a small MP3 file" crap, because you know some doofus will just look at that code and think "Hey, it worked for MP3, what about AVI files?".

---

Ok... I see your point and I've done things that way too... but with decent sized buffers ... 256k or such... not character by character...

Quote:

---

Originally Posted by CommonTater

Ok... I see your point and I've done things that way too... but with decent sized buffers ... 256k or such... not character by character...

---

The problem is that you gave him an example which may result in bad habits and severely affect his coding style. Think what can happen in the future if he works as a programmer in a big company. He may be involved in a large desktop application sold to thousands of customers worldwide.

Suddenly it will crash.

Do you want to be responsible for this?

Shame on you.

:o

Copying by reading byte by byte and reading all are two extremes that you should avoid. ;) LOL

Quote:

---

Originally Posted by kmdv

The problem is that you gave him an example which may result in bad habits and severely affect his coding style. Think what can happen in the future if he works as a programmer in a big company. He may be involved in a large desktop application sold to thousands of customers worldwide.

Suddenly it will crash.

Do you want to be responsible for this?

Shame on you.

:o

---

(SIGH!) Salem at least had the decency to explain ....

I guess I shouldn't mention that I have programs out there that open 800meg to 1gb files, work on them and then write them back out, all in one big blob... And have been doing that for YEARS without problems...

Doing something wrong years does not make it right. ;)
May be your program always run fine on same machine, same platform, etc... you need to consider... these all.(environment that your code will run).
My laptop has only 1GB of memory. Do you know how much my system hangs when I allocate just 500MB with malloc()?

Quote:

---

Originally Posted by Bayint Naung

Doing something wrong years does not make it right. ;)
May be your program always run fine on same machine, same platform, etc... you need to consider... these all.(environment that your code will run).
My laptop has only 1GB of memory. Do you know how much my system hangs when I allocate just 500MB with malloc()?

---

Tell ya what... in anything that got beyond my own hard disk, I would have --and always do-- include a lot more error checking. I was trying to give the OP a concept --an idea-- not redistributable code...

In any case, the point is made, and I agree a smaller buffer and a loop would have been better...

In future I will mark these things with "Provided to show concept only"

Yes I know the code is not important. but the concept in the code is not really a good one.
Edit: I think there's no point continuing discussion either. ;)

Quote:

---

Originally Posted by Bayint Naung

Yes I know the code is not important. but the concept in the code is not really a good one.
Edit: I think there's no point continuing discussion either. ;)

---

It's fine to continue far as I'm concerned... but maybe we should get back to the OP and his problem...

Quote:

---

Originally Posted by CommonTater

It's fine to continue far as I'm concerned... but maybe we should get back to the OP and his problem...

---

Sure. Look, your post count will reach 5k soon. I am looking forward to seeing this :O

why is it not working with ch?
this question is for salem for his first post.

Quote:

---

Originally Posted by shubham

why is it not working with ch?
this question is for salem for his first post.

---

It probably works just fine as you're doing it... but copying files character by character is painfully slow.

My suggestion was to do it in large chunks with fread() and fwrite()... even whole files at once in some cases.

EOF is guaranteed to be a negative number outside the range of char. So you squish it back and forth trying to fit it into a byte and then promote it to compare it with something bigger than a byte.

Let's pretend that instead of bytes, the only thing you can read are single bits. EOF is defined in our example as 10 in binary, and all you can read is 0 or 1.

Code:

---

do
    bit = readbit( file ); /* read 1 or 0 */
while( bit != 10 ); /* promote a single bit into two bits to compare */

---

Ok, so our file is: 001100 in bits. Then it is EOF. What happens in this comparison:

0 is read, 0 is promoted to 00 and compared with 10
0 is read, 0 is promoted to 00 and compared with 10
1 is read, 1 is promoted to 01 and compared with 10
1 is read, 1 is promoted to 01 and compared with 10
0 is read, 0 is promoted to 00 and compared with 10
0 is read, 0 is promoted to 00 and compared with 10
10 is read, squished into 0, promoted back to 00 and compared with 10

You have just read the EOF marker, but your program doesn't know you are at EOF, so you merrily read off past the end of your file until your program crashes or something else odd happens. In any event, you have no idea when you've reached the end of your file.


Quzah.

what is the value of EOF?

Quote:

---

Originally Posted by shubham

what is the value of EOF?

---

I just told you:

Quote:

---

Originally Posted by quzah

EOF is guaranteed to be a negative number outside the range of char.

---

There is no one specific value, it can be anything negative that is outside the range of a char.


Quzah.

i think it's value is -1 ? but i am not sure. that's why i seek your help quzah

Quote:

---

Originally Posted by shubham

i think it's value is -1 ? but i am not sure. that's why i seek your help quzah

---

Listen to what Quzah is telling us... it could be *any value* that is not a valid ascii or ansi character...
If you test for -1 and it gets recompiled on a system where it's -128... what happens?

That is one of the reason we use constants like EOF or MAX_INT in C... because those values can and do change from one compiler to the next.