Привет всем.Сегодня узнал о новой технологии хранения информации в алмазах стёклах кварцевых пластинках и прочих кристаллах.

В Гугле нашел вот такую информацию.

>>Рекордные показатели могут быть достигнуты при использовании пятимерных наноструктур в стеклянных пластинах. Группой сотрудников в Исследовательском центре оптоэлектроники Университета Саутгемптона создан прототип размером с монету в 25 центов, способный хранить 360 терабайт данных и выдержать температуру до 190 °C. Исследователи полагают, что их изобретение сможет хранить данные до 13.8 миллиардов лет (возраст Вселенной) поскольку, в отличие от CD и DVD, где данные записаны на поверхности и могут пострадать от царапин, 5-мерные стеклянные диски хранят информацию в своей структуре, где данные не подвержены ударам и царапинам.<<

Но ничего не сказано про устройство считывания и записи на эти пластинки вроде как за такими пластинками будуюшее но если считыватель будет на лазере как в cd то это неудачная затея лазеры садяться со временем.Может кто то уже знает про эти технологии или другие прорывные виды хранения информации? спасибо всем за внимание и понимание.

| Сообщение посчитали полезным:

SDK пишет:
это так все умеют может вы умеете сильнее ужать ?
Ну если от 1 до 4000 байт в торсионное поле разве что выгружать временно. Этот файл был получен из сжатого deflate'ом и зашифрованного aes-256 текстового файла. То, что ты нашел кодек, который обвесив это управляющими кодами, умудрился добиться выигрыша в размере хотя бы в 1 байт, событие маловероятное.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
событие маловероятное. ну я не знаю я в этой теме только часов 7 но знающие люди из Сельских Штатов Америки 20-25 лет назад уже выкладывали свои идеи о сжатии файлов которые не возможно сжать я их почитал почти все они пишут что у них есть рабочий алгоритм и они хотят или денег или признания славы но их высмеивают. Там всякие сложные переконвертирования новые системы счисления и прочее что сложно для меня. поэтому я придумал свой взял ручку тетрадку чтоб примерно зарисовать блочно что там происходит и спомошью редактора файлов в ручном или уже в полу-автоматическом режиме мне удалось уменьшить размер файла somedata c 1,00 МБ (1 048 576 байт) до 0,99 МБ (1 044 573 байт) на 4003 байт файл уменьшился.на это ушло где то минут 5 работы компьютера для декомпрессии уйдёт столько же.

| Сообщение посчитали полезным:

А я ничего другого и не ожидал.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
А я ничего другого и не ожидал.
А давайте тогда придумаем другой способ уменьшения файлов и соберём хотяб для начала консольное win32 приложение способное на ужатие вашего файла на 4003-4099 байт.

| Сообщение посчитали полезным:

SDK пишет:
Там всякие сложные переконвертирования новые системы счисления и прочее что сложно для меня
Двоичная система - это самая эффективная форма записи информации. Никакими переконвертированиями ты не уменьшишь объем информации (в общем случае) даже на один БИТ. Это тоже сложно?

| Сообщение посчитали полезным:

та нее задача была для меня ужать файл финда любыми доступным мне способом , что у меня получилось это сжать на 4 099 байт думаю может финд сам придумает что то по лучше моего метода и покажет он дядька умный. ну а так я думаю теперь взять архиватор рошалда и подкрутить его алгоритм который при добавлении файла в архив даст не прирост а выйгрыш ну пусть будет от 1-1000 байт это уже будет более менее интереснее использовать рар как дополнительный упаковшик. есть еще три идеи они обсуждались на заграничных форумах там использовался paq и szip с этого сайта http://www.compressconsult.com

| Сообщение посчитали полезным:

Я ничего в твоей картинке не понял (вероятно так и было задумано). То, что ты чего-то там в "полуручном режиме" сжал скорей всего дешевый треп, никаких аргументов в пользу этого ты не представил. "Знающие люди" - это тот дебил, который число комбинаций из 10 бит не смог посчитать? Для чего он упомнянут? Ссылки какие-то, аббревиатуры из 3 и 4 букв - зачем это? Ты заявил, что сжал файл - где сжатый? Где алгоритм?

-----
2 оттенка серого

| Сообщение посчитали полезным:

SDK пишет:
что у меня получилось это сжать на 4 099 байт
Кодес в студию. Так уж и быть, покажем тебе, где ты ошибся

| Сообщение посчитали полезным:

На картинке я показал принцип

Добавлено спустя 10 минут
Берём файл находим байт например буква А в 16й и выкидываем его отрезаем все последующие данные сохраняем
Дальше так же разбивает на куски оставшиеся файлы получается от 2 до 4000 файлов без того самого байта а потом при сборке добавляем в разрыв а для того чтоб и размер на диске был такой же в свойствах названия каждого файла вырываются из тела сигмента и записываются как имя а декомпрессор это все собирает это самый простой способ который я придумал на счёт алгоритма бабушкина и Криса Касперского оказалось это из фантастического рассказа идея от инопланетян там они на сапфировом алмазе умеют хранить всю информацию переводя её в дробь так что идея эта не их и обсуждалась 20 лет назад заграницей

| Сообщение посчитали полезным:

SDK пишет:
Берём файл находим байт например буква А в 16й и выкидываем его отрезаем все последующие данные сохраняем
Ты выкидываешь комбинацию из 8 бит, как ты будешь кодировать служебную информацию для их восстановления на прежнем месте, используя менее 8 бит? Вот про напланетян вообще не надо.

-----
2 оттенка серого

| Сообщение посчитали полезным:

Используется атрибут времяни создания файла в ручном управлении в автоматическом я до этого ещё не докрутил мне была интересна строка размер файла а не размер служебной информации

Добавлено спустя 3 минуты
В ручном режиме всё работает можете сами докруть автоматику идею я вам дал

| Сообщение посчитали полезным:

SDK пишет:
Используется атрибут времяни создания файла но я до этого ещё не докрутил мне была интересна строка размер файла а не размер служебной информации
Банный стыд. Ты предлагаешь напилить файл на кучу мелких n-ного размера, не заботясь о том, сколько в файловой таблице архива каждая из них будет занимать. А я бы посоветовал поинтересоваться, если твой компрессор будет с более чем 4гб файлами работать, каждая запись будет не меньше 32 бит, а исключил ты из каждой строки сраные 8.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
как ты будешь кодировать служебную информацию для их восстановления на прежнем месте
Ну че тупишь? Файлы с фрагментами именуем block_NNN_insert_A_before.bin, складываем их в один каталог и пакуем потом зипом.

Наверное, не стоит вскрывать эту тему далее, чтобы не закончить как гражданин Слоот.

| Сообщение посчитали полезным:

rmn пишет:
Ну че тупишь? Файлы с фрагментами именуем block_NNN_insert_A_before.bin, складываем их в один каталог и пакуем потом зипом.
Ага, зип-заголовок каждого файла займет 65 байт плюс длина имени файла. Это я напомню чтобы исключить 1 байт.

Если направить эту мысль в сторону чего-то разумного, то препроцессор должен находить повторяющиеся блоки такой длины, чтобы совокупная длина всей служебной информации внутри поля данных и в словаре была меньше совокупной длины всех таких блоков в исходном буфере. И в конце пути нас ждет очередная вариация лемпеля-зива со словарем и без бегущего окна. Данные с высокой дифференциальной энтропией эта хрень жать не станет. Потому что так часто повторяющихся блоков сколь-нибудь значимой длины (какая неожиданность) в них не будет.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
если твой компрессор будет с более чем 4гб файлами работать,
я о таком и мечтать не думал даже моя задача пока что тренироваться с вашим файлом если еще кто нибудь подкинет то размер более 10 мб мой компьютер уже не обработает это потребует новое оборудование время на компрессию декомпресию и тд

это просто лабараторная работа но а если мы захотим собрать работающий качественный нормальный продукт
то нам уже потребуются собрать настоящий архиватор из следующих блоков:

1.Компрессор с алгоритмом тестирующим максимальный повторяемый байт в файле. A (1010) B (1011 ) C (1100) D (1101) E (1110) F (1111) например это байт F (сохраняемый выбраный результат в декомпрессор)

2.Делитель файлов который будет разбивать файлы на блоки При обноружении F в теле с удалением последующего и отщеплением последующей информации,что бы сохранить дисковое пространство (если это важно) использоваться в качестве имён будет тело самого блока с вычитанием его из тела и переносом в имя опрёделенного количества символов.

3.Написание блочного декомпрессора
3.1 который считает атрибут создания файла
3.2 выстроит цепочку
3.3 добавит не достающий код из названия ( что бы уровнять размер на диске к размеру файла если это нужно) в каждый блок
3.4 Добавить вырезанный байт который записал компрессор с алгоритмом тестирующим максимальный повторяемый байт в файле из 1 пункта. в каждый блок.
3.5 Построение рабочего файла путём вставки всей цепочки блоков в исходный файл.

Если эту работу разбить на отдельные приложения которые работают в ручном виде и заставить делать студентов то это не сложно но если заставить это всё делать 1 го человека то даже вы f13nd и rmn сделать этого не сможете из за объёма работы и потому что не верете в успех дела.

поэтому я пока отложу это тяжелое для меня занятие и по намёкам заграничных сподвижников буду ковыряться в рар архиве там как оказывается есть нюансы и программное обеспечение уже разработано выглядит презентабельно остаётся только после сборки-обработать напильником! о ходе работ и тестах я буду отписывать на глав почтамт.

Но возможно я ошибаюсь и Вас потянет на приключение или посетят более интересные идеи и вы мне утрёте нос сжав по всем научным правилам и законам файл somedata.

| Сообщение посчитали полезным:

SDK пишет:
это просто лабараторная работа но а если мы захотим собрать работающий качественный нормальный продукт
Какой еще продукт, твоя поделка даже в теории не работает.

-----
2 оттенка серого

| Сообщение посчитали полезным:

SDK
Специально для вас --> Link <--

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

решил сжатие файла финда тремя разными способами теперь послушаю вас
как вы решили эту задачу.Только не говорите что это не возможно.

| Сообщение посчитали полезным:

SDK пишет:
решил сжатие файла финда тремя разными способами
Один из них мы уже видели

-----
2 оттенка серого

| Сообщение посчитали полезным:

есть у нас такая картинка
1 261 байт png 1 204 байт jpg

все на этом форуме могут сжать её например в 400-500 байт ?

| Сообщение посчитали полезным: