0

I'm attempting to read the contents of a .3gp file as a string to later save that string as a valid .3gp file once again.

When I read the string contents, it seems to be differently encoded than when I look at the string contents of a .3gp file on Windows.

Here is an excerpt from the beginning of the string contents I received:

\u0000\u0000\u0000\u0018ftyp3gp4\u0000\u0000\u0000\u0000isom3gp4\u0000\u0000\t�moov\u0000\u0000\u0000lmvhd\u0000\u0000\u0000\u0000�o�K�o�K\u0000\u0000\u0003�\u0000\u0000 �\u0000\u0001\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000@\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0002\u0000\u0000\u0000�meta\u0000\u0000\u0000!hdlr\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000mdta\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000dkeys\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0003\u0000\u0000\u0000\u001bmdtacom.android.version\u0000\u0000\u0000 mdtacom.android.manufacturer\u0000\u0000\u0000\u0019mdtacom.android.model\u0000\u0000\u0000`ilst\u0000\u0000\u0000\u001d\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0015data\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u00008.1.0\u0000\u0000\u0000\u001e\u0000\u0000\u0000\u0002\u0000\u0000\u0000\u0016data\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000Google\u0000\u0000\u0000\u001d\u0000\u0000\u0000\u0003\u0000\u0000\u0000\u0015data\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000Pixel\u0000\u0000\b1trak\u0000\u0000\u0000\tkhd\u0000\u0000\u0000\u0007�o�K�o�K\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000

A valid .3gp file's contents when opened in Notepad on Windows look like the following excerpt shows:

ftyp3gp4 isomiso23gp4 free -kmdat<§!4ˆÉ‡€èÕ_ÒA@€ vÞm¾ ©°Ï@; €$::=>zá!3³³Ó×ùžŸ8HLììøýÂBg‡‡çî<f¦§QÓ3366sŽ™™‘©£œtÌLÌ#f\bé2ÒÂòçXÉ••–:ÅÌ œ¬¥Ú.däÅ$îñS%$&%w‰š|„ÐѤ&€‚ˆŠÝ#4TVé  £#7ÈÍ ºFˆGУ#7ÈÄ„}¾Fh((ˆò2 ¡ *Šïšy¾AÉùñí*W…ÿŠ£MÛJ…È»4ò\ÇÃú£×©ÎC—‰ñôŸü™Iœž(²z™¦ÿå;õÕ®]ÁB>ªÇŠGma,H(â > tNÊvt~b$ _W¿¢4•¶Ñ9Ñ_â©¥„ñž—÷ ¡æñ¹ ͨéZç£JmdÁ÷•ƒ_sÊvîü¾òµÉÒ̃S±,yðÆ4¼?ü0MU†ÝKÞ £ÏÊÑ#£n1t”ØâX<Oã£ïBAx!—O²×ÈáÄ’àB/¾a¿LÔÐàÝÊ:f†fÆÎqÓ1043s™yq‘‹¤dËJËËc&VRZXë2‚r¢—h©¢£%%7IJŽŽ––}¶J4„ƒé‰²SHIMMm’‰$úJjkd•O¥MMm’šRJjklœÒRSS[dãHG>˜–Ý$ÝÈ-ò¥jýš§;‡’ÎBýT+Un[uÎÁAøn(HÀCñöÈBOǪÆ'@–¨ºAÜØ|qí½"yOÕ]1¨ò¿cm €<IT%´¡$h I/@ô˜Õ4‘@èõI– BŠtóÊÇʽoAË}PÊ’ž!/.QퟪóÍæjF@ÀzP>@B®—ùUôùbi%VýVüw»ÞÓÎ àñ^{s$t~/ÕÕj•+ËTU{k“¦ÏNÕ
ËÇíE°2->ú¸\¬w?ù¸:“‰NÏt‰’XÇIP5f‰P^€9TT%LªTŽÆ°ÁXôKþÌÁÖLìé ùÆ>g'§Ž1ó65:9rŽ™¡™¹«œtÌL #&^\bé2ÂÂâçXÈ“O¦¨(¶IQ8úyõ%6¹J(P>¦¦×'…ê'ÕOµÉõê'ÕOªŸj”ê'ÔOªŸU>×)ÔO¨ŸU>ª}®N5ꪒsPNTSl“šrjš‹d›4ĵì‹:Kjïf–”žœâ•›ÈÕ‚Ÿè^òÀÕU kËâ§Ù|lœ€Á°aÿ|0ÇõPþ7s÷ÕE6zHä'•ÕûiǔŠ£œÒ¿Úó}TªP­²tÅ}|A‹çøª¢‡Â ü¹GUÉSÜ{TH¯|y'Æ’A€ ÷à‘».Óp€ÀyßQ&,³#K™• û|ŒÐÑ›äfzv€~á!3£ƒÓ·ù›šœœ9GÌÐÌØÙÎ6f&†n‘³TUWYk“šª²ÒÓT¥•Ï«Ÿ[>¸Õ)Eƒë×Zef²²ººÕ)5••ÕÖ©I¬¬®®µJÑdú¹õÕ¶¹Z+ŸV>¶¶×'Ecê§Ö–Zå,¨}LúÁõ†ÉI©©

I believe the type of string I've received is Base64 based on some searches I did, and I've noticed processing the string in javascript with unescape(encodeURIComponent()) gives me a somewhat similar result to the valid .3gp contents, but it's not exact.

Does anyone know what I need to do to the string to make it look like the valid .3gp file string contents in Windows? Is this even possible at all?

BirdLaw
  • 572
  • 6
  • 16
  • 1
    It doesn't look like base64. It looks like utf16. How did you read this in? – Jim B. Jan 02 '18 at 01:22
  • 1
    How are you reading the file and how are you printing the data? You have a bunch of `\u0000` which are null bytes. – MinusFour Jan 02 '18 at 01:28
  • 1
    That's *not* Base64. I suspect it's *raw bytes* (as well, .3gp/movies are binary data files) - if so, attempting to open this as any kind of "string" is *wrong*. (Notepad or another text editor will usually have it's own particular kind of 'wrongness', depending on encoding and how invalid data is treated). Instead of dealing with strings/text, use byte sequences (and binary editors).. – user2864740 Jan 02 '18 at 01:28
  • I read the file from an android smartphone using a React Native javascript library called Expo. I'm not sure where I got the idea that it was Base64, but it sounds like that's definitely not the case. It's actually just an audio file, but the way Android saves audio is apparently as either a .3gp or .mp4. Could that be why there are a lot of null bytes? – BirdLaw Jan 02 '18 at 01:31
  • I think due to limitations of javascript with regard to opening files on the client, the Expo.js api only seems to have the ability to read file contents as a string. Is it impossible for me to make use of the string contents provided by Expo, then? – BirdLaw Jan 02 '18 at 02:14
  • @JimBaldwin This website leads me to believe the string is a "JSON/Javascript/Java String" https://www.percederberg.net/tools/text_converter.html using the tool at the website to convert it to UTF-8 plain text seems very similar to the contents of the .3gp file... – BirdLaw Jan 02 '18 at 02:40
  • It really depends on what you want to do with the file. Do you need to process it, or are you just saving it somewhere? – Jim B. Jan 02 '18 at 02:46
  • @JimBaldwin I only need to save it to a server, and then download it and save as .3gp file for playback – BirdLaw Jan 02 '18 at 02:49

1 Answers1

1

Since you only need to be able to download it, holding it as a string is fine. If you can use a Node Buffer instead, it will be a bit more robust, but javascript string should carry all of your bytes through.

Be careful how you handle the download api to make sure it doesn't get turned into something else.

Jim B.
  • 4,512
  • 3
  • 25
  • 53