Publishing with mp3s vs wav files

[tvcca26887288]

So, I get why Captivate converts an mp3 to a wav file. But as I understand it, it's not supposed to use those wav files when it publishes.

I replaced all of my wavs with mp3s to lower the published file size, but have barely seen any difference whatsoever. My HTML5 zip folder was around 61000KB when I was using wavs and since I replaced them with mp3s, the size has only decreased to 59000. I was expecting it to drop far more drastically. The only thing I can figure is that when Captivate copied all my mp3s to wav files it also decided it was going to publish the wavs.

Is there a way to prevent it from using the .wav file when publishing?

Alternatively, could the cause of the bloating be something unrelated to the audio files?

[Lilybiri]

When publishing Captivate is converting wav's to mp3. Same for images which will be compressed as well. For that reason I recommend to use wav files, instead of custom mp3 files, much better quality will be had when you let Captivate compress the wav-files to mp3 when publishing. The decrease you have seen will probably be due to different compression settings, but it is normal that you will not really have a smaller file size when importing mp3 instead of wav files. If the wav files would have been in the published file, it would have a much larger file size. Audio files are responsible for increasing file size, but also embedded video, and using images that are scaled down in Captivate instead of having the proper size/resolution.

[michaelm71636120]

I do not quite understand why you recommend using wav's. As far as I understand it is as follows:

- If you use a wav, Captivate will convert the wav into an MP3 in the published file.

- If you use an MP3, Captivate will use exactly this MP3 in the published file (without any modifications). Additionally, Captivate will create a wav which can be found in the library but which is not used in the published course.

So if you use an MP3 with perfect audio quality, quality should remain perfect in the end product. Or am I mistaken?

[Lilybiri]

When you insert a MP3, Captivate automatically will create a wav file from that MP3. It is the wav file that will be used when you are editing the audio clip in CP. That means decompressing a compressed file which can always lead to quality loss. Did you check it out that exactly the same compression will be repeated by CP when publishing? That has been my experience, better to give a perfect, non-compressed file (which means wav) and check the settings for CP's compression to mp3.

[Captiv8r]

Perhaps things have changed as it has been a few versions back, but I once asked the Captivate development team about the WAV MP3 thing.

I always knew that it really doesn't matter which format you choose to import. If you import a MP3, the process of importing creates a corresponding WAV inside the Captivate project. And likewise, if you import a WAV, the process of importing creates a corresponding MP3. But when you output, only the MP3 version is actually used.

But when I asked the team about the following scenario, I was told this: If you import an MP3, sure a WAV is created during that process. But if you don't touch it, the untouched MP3 is simply used during the output process.

And sure, I'm guessing compression settings may affect things.

Cheers... Rick

[Lilybiri]

If you don't touch it, but that rarely is the case....

[tvcca26887288]

Okay, I think I get what you guys are saying. I adjusted the volume of my project in Captivate, which I'm guessing forced Captivate to replace all of my MP3s with WAV files for the export. I'm thinking this because in addition to appearing in the library, the WAV files are also now attached to all of my slides where the MP3 files once were. So... assuming I'm understanding this correctly... is it actually better to adjust the volume of the narration outside of the Captivate project in an audio editor? That way when the MP3 gets imported it stays unchanged and is exported instead of a wav?

Also, yes - to the comment about embedded videos above - I was thinking about the YouTube 'embed' code. I'm not a highly technical computer user. That's why I come here to ask questions at least once a week.

[Lilybiri]

It doesn't really matter for the file size, since the wav's will be compressed to mp3 when publishing. Since mostly audio is edited in Captivate, I have recommended to always insert wav-files instead of mp3 to avoid quality loss.

Sorry about the misunderstanding of 'embedded' versus 'linked'.

[michaelm71636120]

Thank you Lilybiri and Captiv8r for clarifying things! So let me summarize:

- If you import an MP3 and do not touch the created wav, Captivate will export precisely the unchanged mp3.

- If you import an mp3 and change the created wav (by editing the audio inside Captivate), Captivate will take the wav and create a new mp3 from that when publishing the course.

In the second case it is better to import a wav in order to avoid quality loss by unnecessary transformations of file format.

[Lilybiri]

Fine summary. Maybe you understand why I recommend always to import uncompressed Wav-files? You never know if you will not edit even something very small in Captivate.

[marya31391609]

My issue with the addition of wav files is that my project file size for some of my courses is massive and using up an unreasonable amount of space on my hard drive. Is there really no setting to prevent the wav clip from being generated? I don't edit my audio in CP, I edit outside of CP and import only mp3's to the library.

[Erik Lord]

.wav files are indeed typically larger than .mp3.

However, you can manage the size of .wav files too.

For one, 'stereo' .wav files are pointless, unless you're actually sending different audio to each channel.

So mix down from stereo to mono. That alone will cut your .wav size in half.

Then, what settings are you using? You definitely want 16bit at minimum but probably don't need 32bit.

44kHz is nice, but I'll bet you won't hear much difference (if the source is good) at 22kHz.

Try that on your .wav files and if that results in manageable sizes...do that. I agree with others that .wav source imported into CP often results in much better final .mp3 audio quality.

And yes, edit outside of CP.

[Lilybiri]

You will not be able to rpevent converting from mp3 to wav, because Captivate offers editing functionality for the audio, which cannot be done to mp3-files. Try to lower all settings for the wav files to lower its size until you have a good balance between quality and file size.

[tvcca26887288]

Wow I didn't think embedding YouTube videos would take up that much room since it's drawing in the videos from elsewhere, but I've got a few of them so that must be the cause of the large file size. Thanks for the info!

[Captiv8r]

Hi there

It's my own understanding that nothing is actually stored in the Captivate output for YouTube. It's totally drawn from YouTube when required.

Cheers... Rick 🙂

[Lilybiri]

I was not talking about Youtube, but about 'embedded videos'.

[Captiv8r]

I suspect that the misunderstanding occurs because of the term "embedded".

What with YouTube offering that "embed code" that can be used.

[Lilybiri]

Sorry, Rick, embedded is the usual term used for all applications: it means that you don't link to an external file, but it is taken up in the file which uses that file. Too often I suppose that users do know the common terminology in IT. In InDesign, Illustrator.... you can embed images or you can link to them. Both work flows exist since eons.

[brendanc52884453]

Lilybiri​ Captiv8r​

I’m sorry to beat this topic into the ground, but I have a follow-up question that relates to this topic: is there any way to prevent Captivate from converting the audio files to mp3 and, instead, utilize the actual wav format?

I’m asking because the LMS is not playing the audio files when I test my course in Firefox.  Each mp3 receives a 500 error from the server.  I know that the issue is server related because of the 500 error and because it works fine on every other server I test on.

I imagine the time it will take to coordinate the right teams to resolve the server conflict will be longer than my deadline. So I’d like to test publishing the course with wav files instead and test that on the LMS, but I don’t think there’s a way to actually do that in 2017.

Any thoughts?  Thanks in advance.

- Brendan

[Lilybiri]

Brendan, the file size of wav files is huge! Look in the Library and compare those sizes with the resulting mp3's. You'll never want the raw Photoshop files to be included in the output neither. There should be a way to solve the server conflict.

[RodWard]

There is no way that I am aware to force Captivate to publish audio to WAV instead of MP3.  As Lilybiri mentions, the MP3 format has superior advantages when downloading because the filesizes are a fraction of WAV equivalents.

It sounds like your web server needs to be configured to allow the MP3 mimetype.  That's the only reason I can think of for it not allowing the audio files to play.  MP3 is now pretty much regarded as the default audio format of the web.  It's highly unusual to find a web server that doesn't have MP3 files set to be served by default.

If your IT people in charge of the web server are worth the cost of a latte then they should know how to fix that issue in about the same time it would take to drink it.

[brendanc52884453]

Lilybiri​ RodWard​

Thank you both for the kind reminder!  I was so caught up in trying to work around the server issue that I think I had my blinders on.

Rod -  Yes, I suggested that they should look into whether mp3 is configured as a mime-type.  But it works on some browsers and not others, so I'm not sure that's it -- my understanding is that a mime-type would impact all clients, regardless of the browser.  I think I found another potential root cause that I've brought to my contact's attention as well, but he's on vacation this week so I was trying to see if I could find a short-term solution to launch the course...

Thank you both for the assistance and prompt replies.  Much appreciated.